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Preface 


Java 9 and its new features add to the richness of the language--one of the most-used 
languages to build robust software applications. Java 9 comes with a special emphasis on 
modularity, implemented from Project Jigsaw. This book is your one-stop guide to 
mastering the changes made to the Java platform. 


The book gives an overview and explanation of the new features introduced in Java 9 and 
the importance of the new APIs and enhancements. Some of the new features of Java 9 are 
groundbreaking, and if you are an experienced programmer, you will be able to make your 
enterprise application leaner by implementing these new features. You will be provided 
with practical guidance in applying the newly acquired knowledge in regards to Java 9 and 
further information on future developments of the Java platform. This book will improve 
your productivity, making your applications faster. By learning the best practices in Java, 
you will become the go-to person in your organization for Java 9. 


By the end of this book, you will not only know the important concepts of Java 9 but you 
will also have a nuanced understanding of the important aspects of programming with this 
great language. 


What this book covers 


Chapter 1, The Java 9 Landscape, explores the most significant features introduced in Java 9, 
including Project Jigsaw, the Java Shell, G1 garbage collection, and reactive programming. 
This chapter provides introductions to these topics, priming them for deeper coverage in 
the subsequent chapters. 


Chapter 2, Discovering Java 9, covers several changes to the Java platform to include heap 
space efficiencies, memory allocation, compilation process improvements, type testing, 
annotations, automated runtime compiler tests, and improved garbage collection. 


Chapter 3, Java 9 Language Enhancements, focuses on the changes made to the Java language. 
These changes impact variable handlers, depreciation warnings, improvements on Project 
Coin changes implemented in Java 7, and import statement processing. 
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Chapter 4, Building Modular Applications with Java 9, examines the structure of a Java 
module as specified by Project Jigsaw and how Project Jigsaw was implemented as part of 
the Java platform. This chapter also reviews the key internal changes to the Java platform as 
they relate to the new modular system. 


Chapter 5, Migrating Applications to Java 9, explores how to migrate Java 8 applications to 
the Java 9 platform. Both manual and semi-automated migration processes are covered. 


Chapter 6, Experimenting with the Java Shell, covers JShell, the new command-line read-eval- 
print loop tool in Java 9. Coverage includes information regarding the tool, the read-eval- 
print loop concept, and the commands and command-line options for use with JShell. 


Chapter 7, Leveraging the New Default G1 Garbage Collector, takes an in-depth look at garbage 
collection and how it is handled in Java 9. 


Chapter 8, Microbenchmarking Applications with JMH, examines how to write performance 
tests using the Java Microbenchmark Harness (JMH), a Java harness library for writing 
benchmarks for the Java Virtual Machine (JVM). Maven is used along with JMH to help 
illustrate the power of microbenchmarking with the new Java 9 platform. 


Chapter 9, Making Use of the ProcessHandle API, reviews new class APIs that enable the 
management of operating system processes. 


Chapter 10, Fine-Grained Stack Tracing, covers the new API that permits an effective means 
of stack walking. The chapter includes detailed information on how to access stack trace 
information. 


Chapter 11, New Tools and Tool Enhancements, covers 16 Java Enhancement Proposals (JEPs) 
that were incorporated into the Java 9 platform. These JEPs cover a wide range of tools and 
updates to APIs to make development with Java easier with greater optimization 
possibilities for our Java applications. 


Chapter 12, Concurrency Enhancements, covers concurrency enhancements introduced with 
the Java 9 platform. The primary focus is the support for reactive programming, a 
concurrency enhancement that is provided by the Flow class API. Additional concurrency 
enhancements introduced in Java 9 are also covered. 


Chapter 13, Security Enhancements, covers several small changes made to the JDK that 
involve security. The security enhancements introduced with the Java 9 platform provide 
developers with a greater ability to write and maintain applications that are more secure 
than previously possible. 
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Chapter 14, Command-Line Flags, explores the command-line flag changes in Java 9. 
Concepts covered in this chapter include unified JVM logging, compiler control, diagnostic 
commands, heap-profiling agent, JHAT, command-line flag argument validation, and 
compiling for older platform versions. 


Chapter 15, Best Practices in Java 9, focuses on working with utilities provided by the Java 9 
platform to include UTF-8 property files, Unicode 7.0.0, Linux/AArch64 port, 
multiresolution images, and common locale data repository. 


Chapter 16, Future Directions, provides an overview of the future developments of the Java 
platform, beyond Java 9. This includes a specific look at what is planned for Java 10 and 
what further changes we are likely to see in the future. 


What you need for this book 


To work with this text, you will need at least a basic knowledge of the Java programming 
language. 


You will also need the following software components: 


e Java SE Development Kit 9 (JDK) 


e http: //www.oracle.com/technetwork/java/javase/downloads/ 


e An Integrated Development Environment (IDE) for coding. Here are suggestions: 


e Eclipse 

e https://www.eclipse.org 
e IntelliJ 

e https://www.jetbrains.com/idea/ 
e NetBeans 


e https://netbeans.org 


Who this book is for 


This book is for enterprise developers and existing Java developers. Basic knowledge of 
Java is necessary. 


[3] 


www.EBooksWorld.ir 


Preface 


Conventions 


In this book, you will find a number of text styles that distinguish between different kinds 
of information. Here are some examples of these styles and an explanation of their meaning. 


Code words in text, database table names, folder names, filenames, file extensions, 
pathnames, dummy URLs, and user input are shown as follows: "Under the subdirectory 
structure of C: \chapter8-benchmark\srce\main\java\com\packt is the 
MyBenchmark. java file." 


A block of code is set as follows: 


public synchronized void protectedMethod () 
{ 


} 
New terms and important words are shown in bold. 


Warnings or important notes appear like this. 


Tips and tricks appear like this. 


Reader feedback 


Feedback from our readers is always welcome. Let us know what you think about this 
book--what you liked or disliked. Reader feedback is important for us as it helps us develop 
titles that you will really get the most out of. 


To send us general feedback, simply email feedback@packtpub.com, and mention the 
book's title in the subject of your message. 


If there is a topic that you have expertise in and you are interested in either writing or 
contributing to a book, see our author guide at www.packtpub.com/authors. 
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Customer support 


Now that you are the proud owner of a Packt book, we have a number of things to help you 
to get the most from your purchase. 


Downloading the example code 


You can download the example code files for this book from your account at http://www. 
packtpub.com. If you purchased this book elsewhere, you can visit http: //www.packtpub. 
com/support and register to have the files e-mailed directly to you. 


You can download the code files by following these steps: 


. Log in or register to our website using your e-mail address and password. 
Hover the mouse pointer on the SUPPORT tab at the top. 

. Click on Code Downloads & Errata. 

Enter the name of the book in the Search box. 

. Select the book for which you're looking to download the code files. 

. Choose from the drop-down menu where you purchased this book from. 

. Click on Code Download. 


ND OU BON 


Once the file is downloaded, please make sure that you unzip or extract the folder using the 
latest version of: 


e WinRAR / 7-Zip for Windows 
e Zipeg /iZip / UnRarX for Mac 
e 7-Zip / PeaZip for Linux 


The code bundle for the book is also hosted on GitHub at https: //github.com/ 
PacktPublishing/Mastering-Java-9. We also have other code bundles from our rich 
catalog of books and videos available at https: //github.com/PacktPublishing/. Check 
them out! 
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Errata 


Although we have taken every care to ensure the accuracy of our content, mistakes do 
happen. If you find a mistake in one of our books--maybe a mistake in the text or the code-- 
we would be grateful if you could report this to us. By doing so, you can save other readers 
from frustration and help us improve subsequent versions of this book. If you find any 
errata, please report them by visiting http: //www.packtpub.com/submit-errata, selecting 
your book, clicking on the Errata Submission Form link, and entering the details of your 
errata. Once your errata are verified, your submission will be accepted and the errata will 
be uploaded to our website or added to any list of existing errata under the Errata section of 
that title. 


To view the previously submitted errata, go to https: //www.packtpub.com/books/ 
content/support and enter the name of the book in the search field. The required 
information will appear under the Errata section. 


Piracy 


Piracy of copyrighted material on the Internet is an ongoing problem across all media. At 
Packt, we take the protection of our copyright and licenses very seriously. If you come 
across any illegal copies of our works in any form on the Internet, please provide us with 
the location address or website name immediately so that we can pursue a remedy. 


Please contact us at copyright @packtpub.com with a link to the suspected pirated 
material. 


We appreciate your help in protecting our authors and our ability to bring you valuable 
content. 


Questions 


If you have a problem with any aspect of this book, you can contact us at 
questions@packtpub.com, and we will do our best to address the problem. 
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Java is already a fully-grown adult in its own right more than two decades since its first 
release. With a stunning community of developers and wide adoption in a number of 
industries, the platform continues to evolve and keep up with the rest of the world in terms 
of performance, security, and scalability. We will begin our journey by exploring the most 
significant features introduced in Java 9, what are the biggest drivers behind them, and 
what more we can expect in subsequent developments of the platform, along with some of 
the things that did not make it in this release. 


In this chapter, we will cover the following topics: 


e Java 9 at 20,000 feet 

e Breaking the monolith 

e Playing around with the Java Shell 

e Taking control of external processes 

e Boosting performance with G1 

e Measuring performance with JMH 

e Getting ready for HTTP 2.0 

e Encompassing reactive programming 
e Expanding the wish list 


Java 9 at 20,000 feet 


You might be asking yourself--isn't Java 9 just a maintenance release with a set of features 
that did not make it into Java 8? There is plenty of new stuff in Java 9 that makes it a distinct 
version in its own right. 
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Inarguably, the modularization of the Java platform (developed as part of project Jigsaw) is 
the biggest piece of work that makes it successfully in Java 9. Initially planned for Java 8, 
but postponed, project Jigsaw is also one of the main reasons why the final release of Java 9 
was further postponed. Jigsaw also introduces a few notable changes to the Java platform 
and is one of the reasons Java 9 is considered a major release. We will explore these features 
in detail in the subsequent chapters. 


The JCP (Java Community Process) provides the mechanisms to turn a set of feature 
proposals (also known as Java Enhancement Proposals or JEPs) into formal specifications 
that provide the basis to extend the platform with new functionality. Java 9 is no different in 
that regard. Apart from the Jigsaw-related Java enhancement proposals, there is a long list 
of other enhancements that made it in Java 9. Throughout this book, we will discuss the 
various features in terms of logical groups based on the corresponding enhancement 
proposals, including the following: 


e The Java Shell (also called JShell)--an interactive shell for the Java platform 

e New APIs to work with operating system processes in a portable manner 

e The Garbage-first (G1) garbage collector introduced in Java 7 is made the default 
garbage collector in Java 9 

e Adding the Java Microbenchmark Harness (JMH) tool that can be used to run 
performance benchmarks against Java applications is included as part of the Java 
distribution 

e Support for the HTTP 2.0 and WebSocket standards by means of a new client API 

e Concurrency enhancements among which is the definition of the F low class, 


which describes an interface for the reactive streams specification in the Java 
platform 


Some of the initial proposals that were accepted for release 9 did not make it there and were 
postponed for a later release, along with other interesting things that developers may expect 
in the future. 


You can download the JDK 9 distribution for your system from http: //www.oracle.com/ 
technetwork/java/javase/downloads/index.html, if you are eager to get your hands dirty 
before trying to move through the other chapters and experimenting with the newly 
introduced samples and concepts. 
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Breaking the monolith 


Over the years, the utilities of the Java platform have continued to evolve and increase, 
making it one big monolith. In order to make the platform more suitable for embedded and 
mobile devices, the publication of stripped down editions such as Java CDC and Java ME 
was necessary. These, however, did not prove to be flexible enough for modern applications 
with varying requirements in terms of functionality provided by the JDK. In that regard, the 
need for a modular system came in as a viral requirement, not only to address 
modularization of the Java utilities (overall, more than 5000 Java classes and 1500 C++ 
source files with more than 25,0000 lines of code for the Hotspot runtime), but also to 
provide a mechanism for developers to create and manage modular applications using the 
same module system used in the JDK. Java 8 provided an intermediate mechanism to 
enable applications to use only a subset of the APIs provided by the entire JDK, and that 
mechanism was named compact profiles. In fact, compact profiles also provided the basis 
for further work that had to be done in order to break dependencies between the various 
distinct components of the JDK required to enable implementation of a module system in 
Java. 


The module system itself has been developed under the name of project Jigsaw on the basis 
of which several Java enhancement proposals and a target JSR (376) were formed. Much 
was put in place to address the requirements of project Jigsaw--there was evidence of 
concept implementation with more features proposed than the ones that successfully made 
it into Java 9. Apart from that, a complete restructuring of the JDK code base has been made 
along with a complete reorganization of the JDK distributable images. 


There was considerable controversy in the community as to whether an existing and mature 
Java module system such as OSGi should be adopted as part of the JDK instead of 
providing a completely new module system. However, OSGI targets runtime behavior such 
as the resolution of module dependencies, installation, uninstallation, starting and stopping 
of modules (also named bundles in terms of OSGI), custom module classloaders, and so on. 
Project Jigsaw however targets a compile-time module system where resolution of 
dependencies happen when the application is compiled. Moreover, installing and 
uninstalling a module as part of the JDK eliminates the need to include it as a dependency 
explicitly during compilation. Furthermore, loading of module classes is made possible 
through the existing hierarchy of classloaders (the bootstrap and the extension and system 
classloaders), although, there was a possibility of using custom module classloaders pretty 
much similar to the module classloaders of OSGI. The latter was, however, abandoned; we 
will discuss Java module classloading in more detail when we talk about the details of the 
module system in Java. 
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Additional benefits from the Java module system include enhanced security and 
performance. By modularizing the JDK and applications into Jigsaw modules, we are able 
to create well-defined boundaries between components and their corresponding domains. 
This separation of concerns aligns with the security architecture of the platform and is an 
enabler of better resource utilization. We have dedicated two detailed chapters to all of the 
preceding points, and to the topic of adopting Java 9 as well, which also requires a degree of 
understanding on the possible approaches to migrating existing projects to Java 9. 


Playing around with the Java Shell 


For a long time, there has been no standard shell shipped with the Java programming 
language to experiment with new language features or libraries or for rapid prototyping. If 
you wanted to do this, you could write a test application with a main method, compile it 
with javac, and run it. This could be done either at the command line or using a Java IDE; 
however, in both cases, this is not as convenient as having an interactive shell for the 
purpose. 


Starting an interactive shell in JDK 9 is as simple as running the following command 
(assuming the bin directory of your JDK 9 installation is in the current path): 


jshell 


You may find it somewhat puzzling that an interactive shell has not been introduced earlier 
in the Java platform as many programming languages, such as Python, Ruby, and a number 
of others, already come with an interactive shell in their earliest versions; However, this had 
still not made it on the priority features list for the earlier Java releases, until now, and it is 
out there and ready for use. The Java shell makes use of a JShell API that provides 
capabilities to enable autocompletion or evaluation of expressions and code snippets, 
among other features. A full chapter is dedicated to discussing the details of the Java shell 
so that developers can make the best use out of it. 
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Taking control of external processes 


Up to JDK 9, if you wanted to create a Java process and handle process input/output, you 
had to use either the Runtime. getRuntime.exec() method, which allows us to execute a 
command in a separate OS process and get a java. lang.Process instance over which to 
provide certain operations in order to manage the external process, or use the new 
java.lang.ProcessBuilder class with some more enhancements in regard to interacting 
with the external process and also create a java. lang .Process instance to represent the 
external process. Both mechanisms were inflexible and also non-portable as the set of 
commands executed by the external processes were highly dependent on the operating 
system (additional effort had to be exerted in order to make the particular process 
operations portable across multiple operating systems). A chapter is dedicated to the new 
process API, providing developers with the knowledge of creating and managing external 
processes in a much easier way. 


Boosting performance with G1 


The G1 garbage collector was already introduced in JDK 7 and is now enabled by default in 
JDK 9. It is targeted for systems with multiple processing cores and a lot of available 
memory. What are the benefits of the G1 compared to previous types of garbage collectors? 
How does it achieve these improvements? Is there a need to manually tune it, and in what 
scenarios? These, and several more questions regarding G1, will be discussed in a separate 
chapter. 


Measuring performance with JMH 


On many occasions, Java applications may suffer from performance degradation. 
Exacerbating the issue is a lack of performance tests that can provide at least a minimal set 
of guarantees that performance requirements are met and, moreover, the performance of 
certain features will not degrade over time. Measuring performance of Java applications is 
not trivial, especially due to the fact that there is anumber of compiler and runtime 
optimizations that may affect performance statistics. For that reason, additional measures 
such as warm-up phases and other tricks must be used in order to provide more accurate 
performance measurements. The Java Microbenchmark Harness is a framework that 
incorporates a number of techniques along with a convenient API that can be used for this 
purpose. It is not a new tool, but is included with the distribution of Java 9. If you have not 
added JMH to your toolbox yet, read the detailed chapter on the usage of JMH in the 
context of Java 9 application development. 
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Getting started with HTTP 2.0 


HTTP 2.0 is the successor of the HTTP 1.1 protocol, and this new version of the protocol 
addresses some limitations and drawbacks of the previous one. HTTP 2.0 improves 
performance in several ways and provides capabilities such as request/response 
multiplexing in a single TCP connection, sending of responses in a server-push, flow 
control, and request prioritization, among others. 


Java provides the java.net .HttpURLConnection utility that can be used to establish a 
non-secure HTTP 1.1 connection. However, the API was considered difficult to maintain 
and further extended with the support for HTTP 2.0 and, so, an entirely new client API was 
introduced in order to establish a connection via the HTTP 2.0 or the web socket protocols. 
The new HTTP 2.0 client, along with the capabilities it provides, will be covered ina 
dedicated chapter. 


Encompassing reactive programming 


Reactive programming is a paradigm used to describe a certain pattern for propagation of 
changes in a system. Reactiveness is not built in Java itself, but reactive data flows can be 
established using third-party libraries such as RxJava or project Reactor (part of the Spring 
Framework). JDK 9 also addresses the need for an API that aids the development of highly- 
responsive applications built around the idea of reactive streams by providing the 
java.util.concurrent .Flow class for the purpose. The Flow class, along with other 
related changes introduced in JDK 9, will be covered in a separate chapter. 


Expanding the wish list 


Apart from all of the new stuff in JDK 9, a whole new set of features is expected in future 
releases of the platform. Among these are the following: 


e Generics over primitive types: This is one of the features planned for JDK 10 as 
part of project Valhalla. Other language enhancements, such as value handles, are 
already part of Java 9 and will be introduced later in this book. 
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e Reified generics: This is another featured part of project Valhalla that aims to 
provide the ability to preserve generic types at runtime. The related goals are 
listed as follows: 

e The foreign functional interface aims to introduce a new API to call 
and manage native functions. The API addresses some of the 
drawbacks of JNI and especially a lack of simplicity for use by 
application developers. The foreign functional interface is 
developed as part of project Panama in the JDK ecosystem. 

e New money and currency API (developed under JSR 354) was 
initially planned for Java 9, but was postponed. 

e New lightweight JSON API (developed under JSR 353) was also 
planned for Java 9, but postponed to Java 10. 


These are just some of the new things one may expect in subsequent releases of the JDK. 
Project Penrose aims to bridge the gap between the module system in Java and the OSGi 
module system, and to provide different methodologies for interoperability between the 
two systems. 


The Graal VM is another interesting research project that is a potential candidate for 
subsequent releases of the Java platform. It aims to bring the runtime performance of Java 
to dynamic languages such as JavaScript or Ruby. 


A chapter dedicated to the future of JDK discusses all of these points in detail. 


Summary 


In this brief introductory chapter, we revealed the small universe of capabilities provided 
by JDK 9. The module system introduced in this release of the platform is indisputably a 
cornerstone in the development of Java applications. We also discovered that a number of 
other major features and changes are introduced in JDK 9 that deserve special attention and 
will be discussed in great detail in subsequent chapters. 


In the next chapter, we will take a look at 26 internal changes to the Java platform. 
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Java 9 represents a major release and consists of a large number of internal changes to the 
Java platform. Collectively, these internal changes represent a tremendous set of new 
possibilities for Java developers, some stemming from developer requests, others from 
Oracle-inspired enhancements. In this chapter, we will review 26 of the most important 
changes. Each change is related to a JDK Enhancement Proposal (JEP). JEPs are indexed 
and housed at openjdk.java.net/jeps/0. You can visit this site for additional information 
on each JEP. 


The JEP program is part of Oracle's support for open source, open 
innovation, and open standards. While other open source Java projects can 
be found, OpenJDK is the only one supported by Oracle. 


In this chapter, we will cover changes to the Java platform. These changes have several 
impressive implications, including: 

e Heap space efficiencies 

e Memory allocation 

e Compilation process improvements 

e Type testing 

e Annotations 

e Automated runtime compiler tests 

e Improved garbage collection 
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Improved Contended Locking [JEP 143] 


The JVM uses Heap space for classes and objects. The JVM allocates memory on the heap 
whenever we create an object. This helps facilitate Java's garbage collection which releases 
memory previously used to hold objects that no longer have a reference to it. Java Stack 
memory is a bit different and is usually much smaller than heap memory. 


The JVM does a good job of managing data areas that are shared by multiple threads. It 
associates a monitor with every object and class; these monitors have locks that are 
controlled by a single thread at any one time. These locks, controlled by the JVM, are, in 
essence, giving the controlling thread the object's monitor. 


So, what is contended locking? When a thread is in a queue for a currently locked object, it 
is said to be in contention for that lock. The following diagram shows a high-level view of 
this contention: 


Request 
Access 


Acquire Lock 
Release Lock 


As you can see in the preceding illustration, any threads in waiting cannot use a locked 
object until it is released. 
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Improvement goals 


The general goal of JEP 143 was to increase the overall performance of how the JVM 
manages contention over locked Java object monitors. The improvements to contended 
locking were all internal to the JVM and do not require any developer actions to benefit 
from them. The overall improvement goals were related to faster operations. These include: 


e Faster monitor enter 
e Faster monitor exit 
e Faster notifications 


The notifications are the notify () and notifyAl1() operations that are called when the 
locked status of an object is changed. Testing this improvement is not something you can 
easily accomplish. Greater efficiency, at any level, is welcome, so this improvement is one 
we can be thankful for even without any easily observable testing. 


Segmented code cache [JEP 197] 


The segmented code cache JEP (197) upgrade was completed and results in faster, more 
efficient execution time. At the core of this change was the segmentation of the code cache 
into three distinct segments--non-method, profiled, and non-profiled code. 


A code cache is the area of memory where the Java Virtual Machine stores 
generated native code. 
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Each of the aforementioned code cache segments will hold a specific type of compiled code. 
As you can see in the following diagram, the code heap areas are segmented by type of 


compiled code: 


Code Heap > 


Complied 
Code 


Non-Method 
Code 


Compiler 
buffers, 
bytecode 
interpreter 


Lightly 
optimized 
profiled 
methods 


Short Lifetime 


Non-Profiled 
Code 


Fully 
optimized 
non-profiled 
methods 


Long Lifetime 


> Permanent 
Lifespan 


Memory allocation 


The code heap containing non-method code is for JVM internal code and consists of a 3 MB 
fixed memory block. The rest of the code cache memory is equally allocated for the profiled 
code and non-profiled code segments. You have control of this via command-line 
commands. 

The following command can be used to define the code heap size for the non-method 
compiled code: 


\ 


-XX : NonMethodCodeCodeHeapSize 


The following command can be used to define the code heap size for the profiled compiled 
methods: 


-XX: ProfiledCodeHeapSize 


The following command can be used to define the code heap size for the non-profiled 
compiled methods: 


-XX:NonProfiledCodeHeapSize 


This Java 9 feature certainly stands to improve Java application efficiency. It also impacts 
other processes that employ the code cache. 
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Smart Java compilation, phase two [JEP 
199] 


The JDK Enhancement Proposal 199 is aimed at improving the code compilation process. 
All Java developers will be familiar with the javac tool for compiling source code to 
bytecode, which is used by the JVM to run Java programs. Smart Java Compilation, also 
referred to as Smart Javac and sjavac, adds a smart wrapper around the javac process. 
Perhaps the core improvement sjavac adds is that only the necessary code is recompiled. 
Necessary code, in this context, is code that has changed since the last compile cycle. 


This enhancement might not get developers excited if they only work on small projects. 
Consider, however, the tremendous gains in efficiency when you continuously have to 
recompile your code for medium and large projects. The time developers stand to save is 
enough reason to embrace JEP 199. 


How will this change how you compile your code? It probably will not, at least not yet. 
Javac will remain the default compiler. While sjavac offers efficiencies regarding 
incremental builds, Oracle has deemed it to not have sufficient stability to become part of 
the standard compilation workflow. 


You can read more information about the smart javac wrapper tool here: 
http://cr.openjdk.java.net/~briangoetz/JDK-8030245/webrev/src/ 


share/classes/com/sun/tools/sjavac/Main.java-.html. 


Resolving Lint and Doclint warnings [JEP 
212] 


Do not worry if you are not familiar with Lint or Doclint in Java. As you can determine 
from the section title, they are sources that report warnings to javac. Let's take a look at each 
one: 


e Lint analyzes byte code and source code for javac. The goal of Lint is to identify 
security vulnerabilities in the code being analyzed. Lint can also provide insights 
into scalability and thread locking concerns. There is more to Lint, and the overall 
purpose is to save developers time. 
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You can read more about Lint here: 
https://en.wikipedia.org/wiki/Lint_(software). 


e Doclint is similar to Lint and is specific to javadoc. Both Lint and Doclint report 
errors and warnings during the compile process. Resolution of these warnings 
was the focus of JEP 212. When using core libraries, there should not be any 
warnings. This mindset led to JEP 212, which has been resolved and implemented 
in Java 9. 


A comprehensive list of the Lint and Doclint warnings can be reviewed in 
the https: //bugs.openjdk. java.net JDK Bug System. 


Tiered attribution for javac [JEP 215] 


JEP 215 represents an impressive undertaking to streamline javac's type checking schema. 
Let's first review how type checking works in Java 8; then we will explore the changes in 
Java 9. 


In Java 8, type checking of poly expressions is handled by a speculative attribution tool. 


Speculative attribution is a method of type checking as part of javac's 
compilation process. It has a significant processing overhead. 


Using the speculative attribution approach to type checking is accurate, but lacks efficiency. 
These checks include argument position, and are exponentially slower when testing in the 
midst of recursion, polymorphism, nested loops, and lambda expressions. So the goal with 
JEP 215 was to change the type checking schema to create faster results. The results 
themselves were not inaccurate with speculative attribution; they were just not generated 
rapidly. 
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The new approach, released with Java 9, uses a tiered attribution tool. This tool implements 
a tiered approach for type checking argument expressions for all method calls. Permissions 
are also made for method overriding. In order for this new schema to work, new structural 
types are created for each of the following listed types of method arguments: 


e Lambda expressions 

e Poly expressions 

e Regular method calls 

e Method references 

e Diamond instance creation expressions 


The changes to javac from JEP 215 are more complex than what has been highlighted in this 
section. There is no immediate impact to developers other than a more efficient javac and 
time saved. 


Annotations pipeline 2.0 [JEP 217] 


Java annotations refer to a special kind of metadata that resides inside your Java source 
code files. They are not stripped by javac, so that they can remain available to the JVM at 
runtime. 


Annotations look similar to JavaDocs references because they start with the @ symbol. There 
are three types of annotations. Let's examine each: 


e The most basic form of annotation is a marker annotation. These are standalone 
annotations with the only component being the name of the animation. Here is an 
example: 


@thisIsAMarkerAnnotation 
public double computeSometing(double x, double y) 
{ 

// do something and return a double 


} 
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e The second type of annotation is one that contains a single value, or piece of data. 
As you can see in the following code, the annotation, which starts with the @ 
symbol, is followed by parentheses containing data: 


@thisIsAMarkerAnnotation (data="compute x and y 
coordinates") 

public double computeSometing(double x, double y) 
{ 


// do something and return a double 


} 


An alternative way of coding the single value annotation type is to omit the dat a= 
component, as illustrated in the following code: 


@thisIsAMarkerAnnotation ("compute x and y coordinates") 
public double computeSometing(double x, double y) 
{ 


// do something and return a double 


} 


e The third type of annotation is when there is more than one data component. With 
this type of annotation, the dat a= component cannot be omitted. Here is an 
example: 


@thisIsAMarkerAnnotation (data="compute x and y 
coordinates", purpose="determine intersecting point") 
public double computeSometing (double x, double y) 

{ 
// do something and return a double 


} 


So, what has changed in Java 9? To answer this question, we need to recall a couple of 
changes introduced with Java 8 that impacted Java annotations: 


e Lambda expressions 
e Repeated annotations 
e Java type annotations 


These Java 8 related changes impacted Java annotations, but did not usher in a change to 
how javac processed them. There were some hardcoded solutions that allowed javac to 
handle the new annotations, but they were not efficient. Moreover, this type of coding 
(hardcoding workarounds) is difficult to maintain. 


So, JEP 217 focused on refactoring the javac annotation pipeline. This refactoring was all 
internal to javac, so it should not be evident to developers. 
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New version-string scheme [JEP 223] 


Prior to Java 9, the release numbers did not follow industry standard versioning--semantic 
versioning. For example, at the time of writing, the last four JDK releases were: 


e JDK 8 update 131 
e JDK 8 update 121 
e JDK 8 update 112 


Semantic versioning uses a major, minor, patch (0.0.0) schema: 

Major equates to new API changes that are not backwards compatible. 
Minor is when functionality is added that is backwards compatible. 
Patch refers to bug fixes or minor changes that are backwards compatible. 


Oracle has embraced semantic versioning for Java 9 and beyond. For Java, a major-minor- 
security schema will be used for the first three elements of Java version numbers: 


e Major: A major release consisting of a significant new set of features 


e Minor: Revisions and bug fixes that are backwards compatible 
e Security: Fixes deemed critical to improve security 


This description of JEP 223 might make the versioning schema seem basic. To the contrary, 
a very detailed set of rules and practices have been developed to manage the future version 
numbers. To demonstrate the complexity, see the following example: 


1 Qin 0 3 27D 19 


Generating run-time compiler tests 
automatically [JEP 233] 


Java is arguably the most used programming language and resides on an increasingly 
diverse number of platforms. This exacerbates the problem of running targeted compiler 
tests in an efficient manner. The purpose of JEP 233 was to create a tool that could automate 
the runtime compiler tests. 
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The tool that was created starts by generating a random set of Java source code and/or byte 
code. The generated code will have three key characteristics: 


e Be syntactically correct 
e Be semantically correct 
e Use a random seed that permits reusing the same randomly-generated code 


The source code that is randomly generated will be saved in the following directory: 


hotspot/test/testlibrary/jit-tester 


These test cases will be stored for later re-use. They can be run from the j-t reg directory or 
from the tool's makefile. One of the benefits of re-running saved tests is to test the stability 
of your system. 


Testing class-file attributes generated by 
Javac [JEP 235] 


The lack of, or insufficient, capability to create tests for class-file attributes was the impetus 
behind JEP 235. The goal is to ensure javac creates a class-file's attributes completely and 
correctly. This suggests that even if some attributes are not used by the class-file, all class- 
files should be generated with a complete set of attributes. There also needs to be a way of 
testing that the class-files were created correctly, in regards to the file's attributes. 


Prior to Java 9, there was no method of testing a class-file's attributes. Running a class and 
testing the code for anticipated or expected results was the most commonly used method of 
testing javac generated class-files. This technique falls short of testing to validate the file's 
attributes. 


There are three categories of class-file attributes--attributes used by the JVM, optional 
attributes, and attributes not used by the JVM. 
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Attributes used by the JVM include: 


e BootstrapMethods 
e Code 


e ConstantValue 


e Exceptions 


e StackMapTable 


Optional attributes include: 


e Deprecated 


e LineNumberTable 


e LocalVariableTable 


e LocalVariableTypeTable 


èe SourceDebugExtension 


e SourceFile 


Attributes not used by the JVM include: 


e AnnotationDefault 

e EnclosingMethod 

e InnerClasses 

e MethodParameters 

e RuntimeInvisibleAnnotations 

e RuntimeInvisibleParameterAnnotations 
e RuntimeInvisibleTypeAnnotations 

e RuntimeVisibleAnnotations 


èe RuntimeVisibleParameterAnnotations 


e RuntimeVisibleTypeAnnotations 


e Signature 


e Synthetic 


[24] 


www.EBooksWorld.ir 


Discovering Java 9 


Storing interned strings in CDS archives 
[JEP 250] 


The method in which strings are stored and accessed to and from Class Data Sharing 
(CDS) archives is inefficient, excessively time consuming, and wastes memory. The 
following diagram illustrates the method in which Java stores interned strings in a CDS 
archive: 


Java Class Data Sharing 


dump to 
shared archive 
file 


classes from private internal 


system jar file representation 


The inefficiency stems from the current storage schema. Especially when the Class Data 
Sharing tool dumps the classes into the shared archive file, the constant pools containing 
CONSTANT_String items have a UTF-8 string representation. 


UTF-8 is an 8-bit variable-length character encoding standard. 


The problem 


With the current use of UTF-8, the strings must be converted to string objects, instances of 
the java.lang.String class. This conversion takes place on-demand which can result in 
slower systems and unnecessary memory usage. The processing time is extremely short, but 
the memory usage cannot be overlooked. Every character in an interned string requires at 
least 3 bytes of memory and potentially more. 


A related problem is that the stored strings are not accessible to all JVM processes. 
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The solution 


CDS archives now allocate specific space on the heap for strings: 


Java Class Data Sharing in Java 9 


classes from private internal dump to shared string space string table 
system jar file representation archive file allocation compression 


The string space is mapped using a shared-string table, hash tables, and deduplication. 


information in an archive. 


i Deduplication is a data compression technique that eliminates duplicative 


Preparing JavaFX UI controls and CSS APIs 
for modularization [JEP 253] 


JavaFX is a set of packages that permits the design and development of media-rich 
graphical user interfaces. JavaFX applications provide developers with a great API for 
creating a consistent interface for applications. Cascading Style Sheets (CSS) can be used to 
customize the interfaces. One of the great things about JavaFX is that the tasks of 
programming and interface design can easily be separated. 


JavaFX overview 


There is a wonderful visual scripting tool called Scene Builder that allows you to create 
graphical user interfaces by using drag and drop and property settings. Scene Builder 
generates the necessary FXML files that are used by your Integrated Development 
Environment (IDE) such as NetBeans. 
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Here is a sample UI created with Scene Builder: 


Sample 


This is a Label 
CheckBox 


WHITE ~ 


Hyperlink 


And, here is the FXML file created by Scene Builder: 


<?xml version="1.0" encoding="UTF-8"?> 

<?import java.lang.*?> 

<?import java.util.*?> 

<?import javafx.scene.control.*?> 

<?import javafx.scene.layout.*?> 

<?import javafx.scene.paint.*?> 

<?import javafx.scene.text.*?> 

<AnchorPane id="AnchorPane" maxHeight="—-Infinity" 


maxWidth="—-Infinity" minHeight="—-Infinity" 
minWidth="—-Infinity" prefHeight="400.0" prefWidth="600.0" 
xmlns:fx="http://javafx.com/fxml/1" 
xmlns="http://javafx.com/javatx/2.2"> 
<children> 
<TitledPane animated="false" collapsible="false" 
layoutX="108.0" layoutY="49.0" text="Sample"> 
<content> 
<AnchorPane id="Content" minHeight="0.0" minWidth="0.0" 
prefHeight="180.0" prefWidth="200.0"> 
<children> 
<CheckBox layoutX="26.0" layoutY="33.0" 
mnemonicParsing="false" prefWidth="94.0" 
text="CheckBox" /> 
<ColorPicker layoutX="26.0" layoutY="65.0" /> 
<Hyperlink layoutxX="26.0" layoutY="103.0" 
text="Hyperlink" /> 
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<Label alignment="CENTER" layoutX="14.0" layoutY="5.0" 
prefWidth="172.0" text="This is a Label" 
textAlignment="CENTER"> 
<font> 
<Font size="14.0" /> 
</font> 
</Label> 
<Button layoutX="81.0" layoutYy="146.0" 
mnemonicParsing="false" text="Button" /> 
</children> 
</AnchorPane> 
</content> 
</TitledPane> 
</children> 
</AnchorPane> 


Implications for Java 9 


Prior to Java 9, JavaFX controls as well as CSS functionality were only available to 
developers by interfacing with internal APIs. Java 9's modularization has made the internal 
APIs inaccessible. Therefore, JEP 253 was created to define public, instead of internal, APIs. 


This was a larger undertaking than it might seem. Here are a few actions that were taken as 
part of this JEP: 


e Moving javaFX control skins from the internal to public API 
(javafx.scene.skin) 


e Ensuring API consistencies 
e Generation of a thorough javadoc 


The following classes were moved from internal packages to a public 
javafx.scene.control.skin package: 


AccordionSkin ButtonBarSkin ButtonSkin CellSkinBase 


CheckBoxSkin ChoiceBoxSkin ColorPickerSkin ComboBoxBaseSkin 


ComboBoxListViewSkin |ComboBoxPopupControl ContextMenuSkin DateCellSkin 


DatePickerSkin HyperLinkSkin LabelSkin LabeledSkinBase 


ListCellSkin ListViewSkin MenuBarSkin MenuButtonSkin 


MenuButtonSkinbase NestedTableColumHeader | PaginationSkin ProgressBarSkin 


ProgressIndicatorSkin|RadioButtonSkin ScrollBarSkin ScrollPaneSkin 


SeparatorSkin SliderSkin SpinnerSkin SplitMenuButtonSkin 
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SplitPaneSkin TabPaneSkin TableCellSkin TableCellSkinBase 


TableColumnHeader TableHeaderRow TableHeaderSkin TableRowSkinBase 


TableViewSkin TableViewSkinBase TextAreaSkin TextFieldSkin 


Text InputControlSkin TitledPaneSkin ToggleButtonSkin TooBarSkin 


TooltipSkin TreeCellSkin TreeTableCellSkin TreeTableRowSkin 


TreeTableViewSkin TreeViewSkin VirtualContainerBase|VirtualFlow 


The public javafx.css package now has the additional classes: 


e CascadingStyle.java:public class CascadingStyle implements 
Comparable<CascadingStyle> 


e CompoundSelector.java:final public class CompoundSelector 
extends Selector 


e CssError.java:public class CssError 


e Declaration.java:final public class Declaration 


èe Rule.java:final public class Rule 


e Selector.java:abstract public class Selector 


e SimpleSelector.java:final public class SimpleSelector extends 
Selector 


e Size.java:final public class Size 


e Style.java:final public class Style 
e Stylesheet .java:public class Stylesheet 


e CssParser.java:final public class CssParser 


Compact strings [JEP 254] 


The string data type is an important part of nearly every Java app. While JEP 254's aim was 
to make strings more space-efficient, it was approached with caution so that existing 
performance and compatibilities would not be negatively impacted. 
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Pre-Java 9 status 


Prior to Java 9, string data was stored as an array of chars. This required 16 bits for each 
char. It was determined that the majority of String objects could be stored with only 8 bits, 
or 1 byte of storage. This is due to the fact that most strings consist of Latin-1 characters. 


@ The ISO Latin-1 Character Set is a single-byte set of character's encodings. 


New with Java 9 


Starting with Java 9, strings are now internally represented using a byte array along witha 
flag field for encoding references. 


Merging selected Xerces 2.11.0 updates into 
JAXP [JEP 255] 


Xerces is a library used for parsing XML in Java. It was updated to 2.11.0 in late 2010, so JEP 
255's aim was to update JAXP to incorporate changes in Xerces 2.11.0. 


i JAXP is Java's API for XML processing. 


Prior to Java 9, the JDK's latest update regarding XML processing was based on Xerces 2.7.1. 
There were some additional changes to JDK 7 based on Xerces, 2.10.0. JEP 255 is a further 
refinement of the JAXP based on Xerces 2.11.0. 


Xerces 2.11.0 supports the following standards: 


e XML 1.0, Fourth Edition 

e Namespaces in XML 1.0, Second Edition 
e XML 1.1, Second Edition 

e Namespaces in XML 1.1, Second Edition 
e XML Inclusions 1.0, Second Edition 
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e Document Object Model (DOM) 


e Level 3 

e Core 

e Load & save 
e Level 2 

e Core 

e Events 


e Traversal & Range 

e Element Traversal, First Edition 

e Simple API for XML 2.0.2 

e Java APIs for XML Processing (JAXP) 1.4 
e Streaming API for XML 1.0 

e XML Schema 1.0 

e XML Schema 1.1 

e XML Schema Definition Language 


The JDK was updated to include the following Xerces 2.11.0 categories: 


e Catalog resolver 

e Datatypes 

e Document Object Model Level 3 
e XML Schema Validation 

e XPointer 


The public API for JAXP was not changed in Java 9. 


Updating JavaFX/Media to newer version of 
GStreamer [JEP 257] 


JavaFX is used for creating desktop and web applications. JavaFX was created to replace 
Swing as Java's standard GUI library. The Media class, javafx.scene.media.Media, is 
used to instantiate an object representing a media resource. JavaFX/Media refers to the 
following class: 


public final class Media extends java.lang.Object 
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This class provides referential data to a media resource. The javafx.scene.media 
package provides developers with the ability to incorporate media into their JavaFX 
applications. JavaFX/Media utilizes a GStreamer pipeline. 


GStreamer is a multimedia processing framework that can be used to 
build systems that take in media from several different formats and, after 
processing, export them in selected formats. 


The purpose of JEP 257 was to ensure JavaFX/Media was updated to include the latest 
release of GStreamer for stability, performance, and security assurances. 


HarfBuzz Font-Layout Engine [JEP 258] 


Prior to Java 9, the layout engine used to handle font complexities; specifically fonts that 
have rendering behaviors beyond what the common Latin fonts have. Java used the 
uniform client interface, also referred to as ICU, as the defacto text rendering tool. The ICU 
layout engine has been depreciated and, in Java 9, has been replaced with the HarfBuzz font 
layout engine. 


HarfBuzz is an OpenType text rendering engine. This type of layout engine has the 
characteristic of providing script-aware code to help ensure text is laid out as desired. 


OpenType is an HTML formatted font format specification. 


The impetus for the change from the ICU Layout Engine to the HarfBuzz Font Layout 
Engine was IBM's decision to cease supporting the ICU Layout Engine. Therefore, the JDK 
was updated to contain the HarfBuzz Font Layout Engine. 
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HiDPI graphics on Windows and Linux [JEP 
263] 


JEP 263 was focused on ensuring the crispness of on-screen components, relative to the 
pixel density of the display. The following terms are relevant to this JEP and are provided 
along with the below listed descriptive information: 


e DPI-aware application: An application that is able to detect and scale images for 
the display's specific pixel density 

e DPI-unaware application: An application that makes no attempt to detect and 
scale images for the display's specific pixel density 


HiDPI graphics: High dots-per-inch graphics 


Retina display: This term was created by Apple to refer to displays with a pixel 
density of at least 300 pixels per inch 


Displaying graphics, both images and graphical user interface components, to the user is 
typically of paramount performance. Displaying this imagery in high quality can be 
somewhat problematic. There is large variability in computer monitor DPIs. There are three 
basic approaches to developing for displays: 


e Develop apps without regard for the potential different display dimensions. In 
other words, create a DPI-unaware application. 

e Develop a DPI-aware application that selectively uses pre-rendered image sizes 
for a given display. 

e Develop a DPI-aware application that properly scales images up/down to account 
for the specific display the application is run on. 


Clearly, the first two approaches are problematic, and for different reasons. With the first 
approach, the user experience is not considered. Of course, if the application was being 
developed for a very specific display with no expected pixel density variability, then this 
approach could be viable. 


The second approach requires a lot of work on the design and development end to ensure 
images for each expected display density are created and implemented programmatically. 
In addition to the tremendous amount of work, the app size will unnecessarily increase, and 
new and different pixel densities will not have been accounted for. 
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The third approach is to create a DPI-aware application with efficient and effective scaling 
capabilities. This approach works well and has been proven with the Mac retina displays. 


Prior to Java 9, automatic scaling and sizing was already implemented in Java for the Mac 
OS X operating system. This capability was added in Java 9 for Windows and Linux 
operating systems. 


Marlin graphics renderer [JEP 265] 


JEP 265 replaced the Pisces graphics rasterizer with the Marlin graphics renderer in the Java 
2D API. This API is used to draw 2D graphics and animations. 


The goal was to replace Pisces with a rasterizer/renderer that was much more efficient and 
without any quality loss. This goal was realized in Java 9. An intended collateral benefit 
was to include a developer-accessible API. Previously, the means of interfacing with the 
AWT and Java 2D was internal. 


Unicode 8.0.0 [JEP 267] 


Unicode 8.0.0 was released on June 17, 2015. JEP 267 focused on updating the relevant APIs 
to support Unicode 8.0.0. 


New in Unicode 8.0.0 
Unicode 8.0.0 added nearly 8,000 characters. Here are the highlights of the release: 


e Ahom script for the Tai Ahom language (India) 

e Arwi, Tamil language (Arabic) 

e Cherokee symbols 

e CJK unified ideographs 

e Emoji symbols along with flesh-tone symbol modifiers 
e Georgian lari currency symbol 

e lk language (Uganda) 

e Kulango languge (Côte d’Ivoire) 
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Updated Classes in Java 9 


In order to fully comply with the new Unicode standard, several Java classes were updated. 
The following listed classes were updated for Java 9 to comply with the new Unicode 
standard: 


e java.awt.font.NumericShaper 
e java.lang.Character 

e java.lang.String 

e java.text.Bidi 


e java.text.BreakIterator 


e java.text.Normalizer 


Reserved stack areas for critical sections 
[JEP 270] 


The goal of JEP 270 was to mitigate problems stemming from stack overflows during the 
execution of critical sections. This mitigation took the form of reserving additional thread 
stack space. 


The pre-Java 9 situation 


The JVM throws a StackOverflowError when it is asked to perform data computation in 
a thread that has insufficient stack space and does not have permission to allocate 
additional space. This is an asynchronous exception. The JVM can also throw the 
StackOverflowError exception synchronously when a method is invoked. 


When a method is invoked, an internal process is used to report the Stack Overflow. While 
the current schema works sufficiently for reporting the error, there is no room for the calling 
application to easily recover from the error. This can result in being more than a nuisance 
for developers and users. If the StackOverflowError was thrown during a critical 
computational operation, the data might be corrupted, causing additional problems. 
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While not the sole cause of these problems, the effected status of locks from the 

Reent rant Lock class were a common cause of undesirable outcomes. This issue was 
evident in Java 7 because the ConcurrentHasMap code implemented the Reent rant Lock 
class. The Concurrent HasMap code was modified for Java 8, but problems still persisted 
for any implementation of the Reent rant Lock class. Similar problems existed beyond just 
ReentrantLock class usage. 


The following diagram provides a broad overview of the StackOverflowError problem: 


Critical Section StackOverflowError 


Continue... 


In the next section, we will look at how this issue was resolved for Java 9. 


New in Java 9 


With the JEP 270 changes for Java 9, a critical section will automatically be given additional 
space so that it can complete its execution and not suffer from the StackOverflowError. 
This is predicated on the additional space allocation needs being small. The necessary 
changes have been made to the JVM to permit this functionality. 


The JVM actually delays the StackOverflowError, or at least attempts to, while critical 
sections are executing. In order to capitalize on this new schema, methods must be 
annotated with the following: 


jdk.internal.vm.annotation.ReservedStackAccess 
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When a method has this annotation and a StackOverflowError condition exists, 
temporary access to the reserved memory space is granted. The new process is, at a high 
level of abstraction, presented as follows: 


Properly 
Critical Section annotated 


Granted temporary 
access to reserved 
space from 
execution stack 


Continue... 


StackOverflowError 


Dynamic linking of language-defined object 
models [JEP 276] 


Java interoperability was enhanced with JEP 276. The necessary JDK changes were made to 
permit runtime linkers from multiple languages to coexist in a single JVM instance. This 
change applies to high-level operations, as you would expect. An example of a relevant 
high-level operation is the reading or writing of a property with elements such as accessors 
and mutators. 


The high-level operations apply to objects of unknown types. They can be invoked with 
INVOKEDYNAMIC instructions. Here is an example of calling an object's property when the 
object's type is unknown at compile time: 


INVOKEDYNAMIC "dyn: getProp:age" 
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Proof of concept 


Nashorn is a lightweight, high-performance, JavaScript runtime that permits embedding 
JavaScript in Java applications. This was created for Java 8 and replaced the previous 
JavaScript scripting engine that was based on Mozilla Rhino. Nashorn already has this 
functionality. It provides linkage between high-level operations on any object of unknown 
type, such as obj . something, where it produces the following: 


INVOKEDYNAMIC "dyn.getProp.something" 


The dynamic linker springs into action and provides, when possible, the appropriate 
implementation. 


Additional tests for humongous objects in 
G1 [JEP 278] 


One of the long-favored features of the Java platform is the behind the scenes garbage 
collection. JEP 278's focus was to create additional WhiteBox tests for humongous objects as 
a feature of the G1 garbage collector. 


WhiteBox testing is an API used to query JVM internals. The WhiteBox 
iy testing API was introduced in Java 7 and upgraded in Java 8 and Java 9. 
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The G1 garbage collector works extremely well, but there was room for some improved 
efficiency. The way the G1 garbage collector worked is based on first dividing the heap into 
regions of equal size, illustrated as follows: 


Simulated Heap 


Equal-Sized 
Regions 


The problem with the G1 garbage collector was how humongous objects were handled. 


A humongous object in the context of garbage collection, is any object that 
Gp takes up more than one region on the heap. 


The problem with humongous objects was that if they took up any part of a region on the 
heap, the remaining space was not able to be allocated for other objects. In Java 9, the 
WhiteBox API was extended with four types of new methods: 


e Methods with the purpose of blocking full garbage collection and to initiate 
concurrent marking. 

e Methods that can access individual G1 garbage collection heap regions. Access to 
these regions consist of attribute reading, such as with the current state of the 
region. 
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e Methods with direct access to the G1 garbage collection internal variables. 
e Methods that can determine if humongous objects reside on the heap and, if so, in 
what regions. 


Improving test-failure troubleshooting [JEP 
279] 


For developers that do a lot of testing, JEP 279 is worth reading about. Additional 
functionality has been added in Java 9 to automatically collect information to support 
troubleshooting test failures as well as timeouts. Collecting readily available diagnostic 
information during tests stands to provide developers and engineers with greater fidelity in 
their logs and other output. 


There are two basic types of information in the context of testing--environmental and 
process. 


Environmental information 


When running tests, the testing environment information can be important for 
troubleshooting efforts. This information includes the following: 


e CPU loads 

e Disk space 

e T/O loads 

e Memory space 

e Open files 

e Open sockets 

e Processes running 
e System events 

e System messages 
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Java process information 


There is also information available during the testing process directly related to Java 
processes. These include: 


e C stacks 

e Core dumps 

e Mini dumps 

e Heap statistics 
e Java stacks 


For additional information on this concept, read about the JDK's 
regression test harness (jtreg). 


Optimizing string concatenation [JEP 280] 


JEP 280 is an interesting enhancement for the Java platform. Prior to Java 9, string 
concatenation was translated by javac into StringBuilder : : append chains. This was 
a sub-optimal translation methodology often requiring StringBuilder presizing. 


The enhancement changed the string concatenation bytecode sequence, generated by javac, 
so that it uses INVOKEDYNAMIC calls. The purpose of the enhancement was to increase 
optimization and to support future optimizations without the need to reformat the javac's 
bytecode. 


See JEP 276 for more information on INVOKEDYNAMIC. 


The use of INVOKEDYAMIC calls to java. lang.invoke.StringConcatFactory allows us 
to use a methodology similar to lambda expressions instead of using StringBuilder's step- 
wise process. This results in more efficient processing of string concatenation. 
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HotSpot C++ unit-test framework [JEP 281] 


HotSpot is the name of the JVM. This Java enhancement was intended to support the 
development of C++ unit tests for the JVM. Here is a partial, non-prioritized, list of goals for 
this enhancement: 


e Command-line testing 

e Create appropriate documentation 

e Debug compile targets 

e Framework elasticity 

e IDE support 

e Individual and isolated unit testing 

e Individualized test results 

e Integrate with existing infrastructure 
e Internal test support 

e Positive and negative testing 

e Short execution time testing 

e Support all JDK 9 build platforms 

e Test compile targets 

e Test exclusion 

e Test grouping 

e Testing that requires the JVM to be initialized 
Tests co-located with source code 


Tests for platform-dependent code 
e Write and execute unit testing (for classes and methods) 


This enhancement is evidence of the increasing extensibility. 


Enabling GTK 3 on Linux [JEP 283] 


GTK+, formally known as the GIMP toolbox, is a cross-platform tool used for creating 
Graphical User Interfaces (GUI). The tool consists of widgets accessible through its API. 
JEP 283's focus was to ensure GTK 2 and GTK 3 were supported on Linux when developing 
Java applications with graphical components. The implementation supports Java apps that 
employ JavaFX, AWT, and Swing. 
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We can create Java graphical applications with JavaFX, AWT, and Swing. Here is a table to 
summarize those three approaches as they relate to GTK, prior to Java 9: 


e Uses a dynamic GTK function lookup 
e Interacts with AWT and Swing via JFXPanel 


e Uses AWT printing functionality 


AWT e Uses a dynamic GTK function lookup 
e Uses a dynamic GTK function lookup 


So, what changes were necessary to implement this JEP? For JavaFX, three specific things 
were changed: 


e Automated testing was added for both GTK 2 and GTK 3 
e Functionality was added to dynamically load GTK 2 
e Support was added for GTK 3 


For AWT and Swing, the following changes were implemented: 


e Automated testing was added for both GTK 2 and GTK 3 
e AwtRobot was migrated to GTK 3 

e FileChooserDilaog was updated for GTK 3 

e Functionality was added to dynamically load GTK 3 

e The Swing GTK LnF was modified to support GTK 3 


iÈ Swing GTK LnF is short for Swing GTK look and feel. 
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New HotSpot build system [JEP 284] 


The Java platform used, prior to Java 9, was a build system riddled with duplicate code, 
redundancies, and other inefficiencies. The build system has been reworked for Java 9 based 
on the build-infra framework. In this context, infra is short for infrastructure. The 
overarching goal for JEP 284 was to upgrade the build system to one that was simplified. 
Specific goals included: 


e Leverage existing build system 
e Maintainable code 

e Minimize duplicate code 

e Simplification 

e Support future enhancements 


You can learn more about Oracle's infrastructure framework at this site: http://www. 
oracle.com/technetwork/oem/frmwrk-infra-496656. html 


Summary 


In this chapter, we covered some impressive new features of the Java platform, with specific 
focus on javac, JDK libraries, and various test suites. Memory management improvements, 
including heap space efficiencies, memory allocation, and improved garbage collection 
represent a powerful new set of Java platform enhancements. Changes regarding the 
compilation process resulting in greater efficiencies were part of our chapter. We also 
covered important improvements, such as with the compilation process, type testing, 
annotations, and automated runtime compiler tests. 


In the next chapter, we will look at several minor language enhancements introduced in 
Java 9. 
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In the previous chapter, we gained insight into some exciting new features contained in 
Java 9. Our focus was on javac, the JDK libraries, and test suites. We learned about memory 
management improvements including memory allocation, heap optimizations, and 
enhanced garbage collection. We also covered changes to the compilation process, type 
testing, annotations, and runtime compiler tests. 


This chapter covers some changes in Java 9 that impact variable handlers, depreciation 
warnings, improvements on Project Coin changes implemented in Java 7, and import 
statement processing. These represent changes to the Java language itself. 


The topics we will cover here are: 


e Variable handlers 

e Import statement depreciation warnings 
e Project Coin 

e Import statement processing 
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Working with variable handlers [JEP 193] 


Variable handlers are typed references to variables and are governed by the 

java. lang. invoke. VarHandle abstract class. The varHandle method's signature is 
polymorphic. This provides for great variability in both method signatures and return 
types. Here is a code sample demonstrating how a VarHandle might be used: 


class Example 
{ 
int myInt; 


} 


class Sample 
{ 
static final VarHandle VH_MYINT; 


static 
{ 
try 
{ 
VH_MYINT = 
MethodHandles.lookup().in(Example.class) 
.findVarHandle(Example.class, "myInt", int.class); 


} 
catch (Exception e) 


{ 


throw new Error(e); 


} 


As you can see in the preceding code snippet, the VarHandle. lookup () performs the 
same operation as those that are performed by a MethodHandle. lookup () method. 


The aim of this JEP was to standardize the way in which methods of the following classes 
are invoked: 


e java.util.concurrent.atomic 


e sun.misc.Unsafe</li> 
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Specifically, methods that: 


e accessed/mutated object fields 
e accessed/mutated elements of an array 


In addition, this JEP resulted in two fence operations for memory ordering and object 
reachability. In the spirit of due diligence, special attention was given to ensure the JVM's 
safety. It was important to ensure that memory errors did not result from these changes. 
Data integrity, usability, and, of course, performance were key components of the 
aforementioned due diligence and are explained as follows: 


e Safety: Corrupt memory states must not be possible. 
e Data integrity: Ensure access to an object's field uses identical rules used by: 
e get field byte code 


e put field byte code 


e Usability: The benchmark for usability was the sun.misc.Unsafe API. The goal 
was to make the new API easier to use than the benchmark. 


e Performance: There could be no degradation of performance compared to the use 
of the sun.misc.Unsafe API. The goal was to outperform that API. 


In Java, a fence operation is what javac does to force a constraint on 
memory in the form of a barrier instruction. These operations occur before 
and after the barrier instruction, essentially fencing them in. 


Working with the AtoMiC Toolkit 


The java.util.concurrent.atomic package is a collection of 12 sub-classes that support 
operations on single variables that are thread-safe and lock-free. In this context, thread-safe 
refers to code that accesses or mutates a shared single variable without impeding on other 
threads executing on the variable at the same time. This superclass was introduced in Java 
7. 
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Here is a list of the 12 sub-classes in the AtoMiC Toolkit. The class names, as you would 
expect, are self-descriptive: 


Atomic subclass 


micBoolean 


cFieldUpdater<T> 


ngFieldUpdater<T> 


micMarkableReference<V> 


Reference<V> 


ReferenceArray<! 


ReferenceFieldUpdater<T, V> 


micStampedReference<V> 


Volatile variables, fields, and array elements can be asynchronously modified by concurrent 


threads. 


In Java, the volatile keyword is used to inform the javac utility to read 
the value, field, or array element from the main memory and not to cache 
them. 


Here is a code snippet that demonstrates the use of the volatile keyword for an instance 


variable: 


public class Sample 


{ 


private static volatile Sample myVolatileVariable; // a 
volatile instance variable 


public static Sample getVariable() // getter method 
{ 

if (myVolatileVariable != null) 

{ 


return myVolatileVariable; 


[ 48 ] 


www.EBooksWorld.ir 


Java 9 Language Enhancements 


} 
// this section executes if myVolatileVariable == null 
synchronized (Sample.class) 
{ 
if (myVolatileVariable == null) 
{ 
myVolatileVariable = new Sample(); 


} 


Using the sun.misc.Unsafe class 


The sun.misc.Unsafe class, like other sun classes, is not officially documented or 
supported. It has been used to circumvent some of Java's built-in memory management 
safety features. While this can be viewed as a window to greater control and flexibility in 
our code, it is a terrible programming practice. 


The class had a single private constructor, so an instance of the class could not easily be 
instantiated. So, if we tried to instantiate an instance with myUnsafe = new Unsafe(),a 
SecurityException would be thrown in most circumstances. This somewhat unreachable 


class has over 100 methods that permitted operations on arrays, classes, and objects. Here is 
a brief sampling of those methods: 


arrayBaseOffset | defineAnonymousClass allocateInstance 
arrayIndexScale|defineclass [object Fieldoffset 
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Here is a secondary grouping of the sun.misc.Unsafe class method for information, 
memory, and synchronization: 


Memory Synchronization 


emory monitorEnter 
emory monitorExit 


putOrderedEdit 
tryMonitorEnter 


The sun.misc.Unsafe class was earmarked for removal in Java 9. There was actually some 
opposition to this decision in the programming industry. To put their concerns to rest, the 
class has been depreciated, but will not be completely removed. A special flag can be sent to 
the JVM to utilize the original API. 


Eliding depreciation warnings on import 
statements [JEP 211] 


This is one of the more simplistic JEPs for Java 9. Quite often, when we compile our 
programs, we receive many warnings and errors. The compiler errors must be fixed as they 
are typically syntactical in nature. The warnings, on the other hand, should be reviewed 
and appropriately addressed. Some of the warning messages are ignored by developers. 


This JEP provides slight relief in the number of warnings we receive. Specifically, 
depreciation warnings caused by import statements are no longer generated. Prior to Java 9, 
we could suppress deprecated warning messages with the following annotation: 


@SupressWarnings 
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Now, with Java 9, the compiler will suppress depreciated warnings if one or more of the 
following cases is true: 


e If the @Deprecated annotation is used 
e If the @SuppressWarnings annotation is used 


e If the use of the warning-generating code and the declaration are within the 
ancestor class 


e If the use of the warning-generating code is within an import statement 


The fourth condition listed was an addition in Java 9. 


Milling Project Coin [JEP 213] 


Project Coin was a feature set of minor changes introduced in Java 7. These changes are 
listed as follows: 


e Strings in switch statements 

e Binary integral literals 

e Using underscores in numeric literals 

e Implementing multi-catch 

e Allowing for more precise re-throwing of exceptions 
e Generic instance creation improvements 


e Addition of the try-with-resources statement 
e Improvements to invoking varargs methods 


Detailed information can be found in the following Oracle presentation: http://www. 


oracle.com/us/technologies/java/project-—coin-428201.pdf. 


JEP 213 focused on improvements to Project Coin's enhancements. There were five such 
enhancements, each detailed as follows. 


Using the @SafeVarargs annotation 


In Java 9, we can use the @SafeVarargs annotation with private instance methods. When 
we use this annotation, we are asserting that the method does not contain any harmful 
operations on the varargs passed as parameters to the method. 
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The syntax for usage is: 


@SafeVarargs // this is the annotation 
static void methodName(...) 


{ 


/* 

The contents of the method or constructor must not 
perform any unsafe or potentially unsafe operations 
on the varargs parameter or parameters. 


af 
} 
Use of the @SafeVarargs annotation is restricted to: 


e Static methods 
e Final instance methods 
e Private instance methods 


The try-with-resource statement 


The try-with-resource statement previously required a new variable to be declared for 
each resource in the statement when a final variable was used. Here is the syntax for the 
try-with-resource statement prior to Java 9 (in Java 7 or 8): 


try ( // open resources ) 
{ 
// use resources 
} catch (// error) 
{ // handle exceptions 
} 


// automatically close resources 
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Here is a code snippet using the preceding syntax: 


try ( Scanner xmlScanner = new Scanner (new File(xmlFile)); 
{ 
while (xmlScanner.hasNext () ) 
{ 
// read the xml document and perform needed operations 
} 
xmlScanner.close(); 
} catch (FileNotFoundException fnfe) 
{ 


System.out.printlin("Your XML file was not found."); 


} 


Now, with Java 9, the try-with-resource statement can manage final variables without 


requiring a new variable declaration. So, we can now rewrite the earlier code, as shown 
here in Java 9: 


Scanner xmlScanner = new Scanner (newFile(xmlFile)); 
try ( while (xmlScanner.hasNext () ) 


{ 


// read the xml document and perform needed operations 
} 
xmlScanner.close(); 
} catch (FileNotFoundException fnfe) 
{ 


System.out.printlin("Your XML file was not found."); 
} 


As you can see, the xml Scanner object reference is contained inside the try-with- 
resource statement block, which provides for automatic resource management. The 


resource will automatically be closed as soon as the try-with-resource statement block 
is exited. 


You can also use a finally block as part of the try-with-resourc 
statement. 
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Using the diamond operator 


Introduced in Java 9, the diamond operator can be used with anonymous classes if the 
inferred data type is denotable. When a data type is inferred, it suggests that the Java 
Compiler can determine the data types in a method's invocation. This includes the 
declaration and any included arguments. 


The diamond operator is the less-than and greater-than symbol pair (<> ). 
It is not new to Java 9; rather, the specific use with anonymous classes is. 


The diamond operator was introduced in Java 7 and made instantiating generic classes 
simpler. Here is a pre-Java 7 example: 


ArrayList<Student> roster = new ArrayList<Student>(); 
Then, in Java 7, we could rewrite it: 
ArrayList<Student> roster = new ArrayList<>(); 


The problem was that this method could not be used for anonymous classes. Here is an 
example in Java 8 that works fine: 


public interface Example<T> 
{ 
void aMethod() 
{ 
// interface code goes her 
} 


} 


Exampl xample = new Example<Integer> () 
{ 
@Override 
public void aMethod() 
{ 
// code 
} 


}; 


While the preceding code works fine, when we change it to use the diamond operator, as 
shown here, a compiler error will occur: 


public interface Example<T> 
{ 
void aMethod() 
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// interface code goes her 


} 


Exampl xample = new Example<>() 
{ 

@Override 

public void aMethod() 

{ 


// code 
} 
‘i 


The error results from using the diamond operator with anonymous inner classes. Java 9 to 
the rescue. While the preceding code results in a compile time error in Java 8, it works fine 
in Java 9. 


Discontinuing use of the underscore 


The underscore character ( _ ) can no longer be used as a legal identifier name. Earlier 
attempts to remove the underscore in an identifier name were incomplete. The use of such 
would generate a combination of errors and warnings. With Java 9, the warnings are now 
errors. Consider the following sample code: 


public class Java9Tests 
{ 
public static void main(String[] args) 
{ 
int _ = 319; 
if ( _ > 300 ) 
{ 


System.out.printin("Your value us greater than 300."); 
} 
else 
{ 
System.out.printin("Your value is not greater than 300."); 
} 
} 
} 
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The preceding code, in Java 8, will result in compiler warnings for int _ = 319; andif 
_ > 300 ) statements. The warning is as of release 9, ’_’ is a keyword, and may not be used as 


an identifier. So, in Java 9, you will not be able to use the underscore by itself as a legal 
identifier. 


It is considered bad programming practice to use identifier names that are 
not self-descriptive. So, the use of the underscore character by itself as an 
identifier name should not be a problematic change. 


Making use of private interface methods 


Lambda expressions were a big part of the Java 8 release. As a follow-up to that 
improvement, private methods in interfaces are now feasible. Previously, we could not 
share data between non-abstract methods of an interface. With Java 9, this data sharing is 
possible. Interface methods can now be private. Let's look at some sample code. 


This first code snippet is how we might code an interface in Java 8: 


public interface characterTravel 
{ 

pubic default void walk() 

{ 
Scanner scanner = new Scanner (System.in); 
System.out.printin("Enter desired pacing: "); 
int p = scanner.nextInt (); 
p=p ti; 


} 

public default void run() 

{ 
Scanner scanner = new Scanner (System.in); 
System.out.printlin("Enter desired pacing: "); 
int p = scanner.nextInt (); 
p=p +4; 


} 

public default void fastWalk () 

{ 
Scanner scanner = new Scanner (System.in); 
System.out.printin("Enter desired pacing: "); 
int p = scanner.nextInt (); 
p=p +2; 

} 

public default void retreat () 

{ 
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Scanner scanner = new Scanner (System.in); 
System.out.printin("Enter desired pacing: 
int p = scanner.nextInt (); 

p =p = Li 


} 
public default void fastRetreat () 


{ 


Scanner scanner = new Scanner (System.in); 
System.out.printin("Enter desired pacing: 
int p = scanner.nextInt (); 

p=p- 4; 


} 


public interface characterTravel 
{ 

pubic default void walk () 

{ 


characterTravel ("walk"); 
} 
public default void run() 
{ 


characterTravel ("run"); 


} 
public default void fastWalk () 


{ 


characterTravel ("fastWalk"); 


} 
public default void retreat () 


{ 


characterTravel ("retreat"); 


} 
public default void fastRetreat () 


{ 


characterTravel ("fastRetreat"); 


} 


")i 


ea 


Now, in Java 9, we can rewrite this code. As you can see next, the redundant code has been 
moved into a single private method called characterTravel: 


private default void characterTravel (String pace) 


{ 


Scanner scanner = new Scanner (System.in); 
System.out.printin("Enter desired pacing: 


int p = scanner.nextInt (); 
if (pace.equals ("walk") ) 
{ 

p =p +1; 


"); 
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} 


else if (pace.equals ("run") ) 


{ 


} 
else if (pace.equals("fastWalk") ) 


p=pt 2; 


else if (pace.equals ("retreat") ) 
{ 

p=p-i; 
} 


else if (pace.equals ("fastRetreat") ) 


Processing import statements correctly [JEP 
216] 


JEP 216 was issued as a fix to javac in regards to how import statements are processed. Prior 
to Java 9, there were instances where the order of import statements would impact if the 
source code was accepted or not. 


When we develop applications in Java, we typically add import statements as we need 
them, resulting in an unordered list of import statements. IDEs do a great job of color- 
coding import statements that are not used, as well as informing us of import statements we 
need but that have not been included. It should not matter what order the import 
statements are in; there is no applicable hierarchy. 


javac compiles classes in two primary steps. Specific to handling import statements, these 
steps are type resolution and member resolution. The type resolution consists of a review of 
the abstract syntax tree to identify declarations of classes and interfaces. The member 
resolution includes determining the class hierarchy and individual class variables and 
members. 
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With Java 9, the order we list import statements in our classes and files will no longer 
impact the compilation process. Let's look at an example: 


In the pr 


package samplePackage; 


import static SamplePackage.OuterPackage.Nested.*; 
import SamplePackage.Thing.*; 


public class OuterPackage 
{ 
public static class Nested implements Inner 
{ 
// code 
} 
i 


package SamplePackage. Thing; 


public interface Inner 


{ 
// code 


} 


eceding example, type resolution occurs and results in the following realizations: 


e SamplePackage.OuterPackage exists 


e SamplePackage.OuterPackage.Nested exists 


e SamplePackage.Thing.Innner exists 


The next step is member resolution, and this is where the problem existed prior to Java 9. 
Here is an overview of the sequential steps javac would use to conduct the member 
resolution for our sample code: 


ey S 


Resolution of SamplePackage.OuterPackage begins. 
The SamplePackage.OuterPackage.Nested import is processed. 
Resolution of the SamplePackage.Outer.Nested class begins. 


The inner interface is type checked, although, because it is not in scope at this 
point, inner cannot be resolved. 

Resolution of SamplePackage. Thing begins. This step includes importing all 
member types of SamplePackage. Thing into scope. 
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So the error occurs, in our example, because Inner is out of scope when resolution is 
attempted. If steps 4 and 5 were swapped, it would not have been a problem. 


The solution to the problem, implemented in Java 9, was to break the member resolution 
steps into additional sub-steps. Here are those steps: 


1. Analyze the import statements. 
2. Create the hierarchy (class and interfaces). 
3. Analyze class headers and type parameters. 


Summary 


In this chapter, we covered changes in Java 9 with regards to variable handlers and how 
they relate to the Atomic Toolkit. We also covered depreciation warnings and why they are 
now suppressed under specific circumstances. Five enhancements to changes introduced 
with Java 7 as part of Project Coin were also reviewed. Finally, we explored the 
improvements to import statement processing. 


In the next chapter, we will examine the structure of a Java module as specified by Project 
Jigsaw. We will take a deep dive into how Project Jigsaw is implemented as part of the Java 
platform. Code snippets from a sample e-commerce application are used throughout the 
chapter to demonstrate Java 9's modular system. Internal changes to the Java platform, in 
regards to the modular system, are also discussed. 
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In the last chapter, we covered changes in Java 9 with regards to variable handlers and how 
they related to the AtoMiC Toolkit. We also covered depreciation warnings and why they 
are now suppressed under specific circumstances. Five enhancements to changes 
introduced with Java 7 as part of Project Coin were also reviewed. Finally, we explored the 
improvements to import statement processing. 


In this chapter, we will examine the structure of a Java module as specified by Project Jigsaw. 
We will take a deep-dive into how Project Jigsaw is implemented as part of the Java 
platform. We will also review key internal changes to the Java platform as they relate to the 
modular system. 


The topics we will cover here are: 


e An introduction to Java modularity 

e Review of the Java platform's module system 
e Modularizing JDK source code 

e Modular runtime images 

e Getting to know the module system 

e Modular Java application packaging 

e The Java linker 

e Encapsulation of internal APIs 
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A modular primer 


Before we dive into the Java 9 enhancements in this chapter, let's examine what modularity 
is in the context of Java. 


We can define the term modular as a type of design or construction, in our context, of 
computer software. This type of software design involves a set of modules that collectively 
comprise the whole. A house, for example, can be built as a single structure or in a modular 
fashion where each room is constructed independently and joined to create a home. With 
this analogy, you could selectively add or not add modules in the creation of your home. 
The collection of modules, in our analogy, becomes the design of your home. Your design 
does not need to use every module, only the ones you want. So, for example, if there are 
basement and bonus room modules and your design does not include those modular 
rooms, those modules are not used to build your home. The alternative would be that every 
home would include every room, not just the ones that are used. This, of course, would be 
wasteful. Let's see how that correlates to software. 


This concept can be applied to computer architecture and software systems. Our systems 
can be comprised of several components instead of one behemoth system. As you can likely 
imagine, this provides us with some specific benefits: 


e We should be able to scale our Java applications to run on small devices 
e Our Java applications will be smaller 

e Our modular code can be more targeted 

e Increased use of the object-oriented programming model 

e Additional opportunities for encapsulation 

e Our code will be more efficient 

e Java applications will have increased performance 

e Overall system complexity is reduced 

e Testing and debugging is easier 

e Code maintenance is easier 


[62] 


www.EBooksWorld.ir 


Building Modular Applications with Java 9 


The shift to a modular system for Java was necessary for several reasons. Here are the 
primary conditions of the Java platform as of Java 9 that led to the creation of the module 
system for the Java 9 platform: 


e The Java Development Kit (JDK) was simply too big. This made it difficult to 
support small devices. Even with the compact profiles discussed in the next 
section, supporting some small devices was difficult at best and, in some cases, 
not possible. 

e Due to the over-sized JDK, it was difficult to support truly optimized 
performance with our Java applications. In this case, smaller is better. 


The Java Runtime Environment (JRE) was too large to efficiently test and 
maintain our Java applications. This results in time consuming, inefficient testing, 
and maintenance operations. 


The Java Archive (JAR) files were also too large. This made supporting small 
devices problematic. 


Because the JDK and JRE were all encompassing, security was of great concern. 
Internal APIs, for example, that were not used by the Java application, were still 
available due to the nature of the public access modifier. 


e Finally, our Java applications were unnecessarily large. 


Modular systems have the following requirements: 


e There must be a common interface to permit interoperability among all connected 
modules 


e Isolated and connected testing must be supported 
e Compile time operations must be able to identify which modules are in use 
e Runtime support for modules 


A module is a new concept and component in Java 9; it is a named collection of data and 
code. Specifically, modules are a collection of: 


e Packages 
e Classes 

e Interfaces 
e Code 

e Data 

e Resources 
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Key to successful implementation, a module in Java 9 is self-described in its modular 
declaration. Module names must be unique and typically use the reverse domain name 
schema. Here is an example declaration: 


module com.three19.irisScan { } 


Module declarations are contained in a module-info. java file that should be in the 
module's root folder. As one might expect, this file is compiled into a module-info.class 
file and will be placed in the appropriate output directory. These output directories are 
established in the module source code. 


In the next sections, we will look at specific changes for Java 9 in regards to modularity. 


Reviewing Java's platform module system 
[JEP-200] 


The core aim of JEP-200 was to modularize the Java Development Kit (JDK) using the Java 
Platform Module System (JPMS). Prior to Java 9, our familiarity with the JDK includes 
awareness of its major components: 


e Java runtime environment (JRE) 
e The interpreter (java) 

e Compiler (javac) 

e The archiver (jar) 

e Document generator (javadoc) 


The task of modularizing the JDK was to break it into components that could be combined 
at compile time or runtime. The modular structure is based on the following modular 
profiles established as compact profiles in Java 8. Each of the three profiles is detailed in the 
following tables: 


Compact profile 1: 


java. java.nio.channels 

java.nio.channels.spi java.nio.charset java.nio.charset.spi 

java.nio.file java.nio.file.attribute java.nio.file.spi 

java.security java.security.cert java.security.interfaces 
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java.util.zip javax.crypto javax.crypto.interfaces 
javax.crypto.spec javax.net javax.net.ssl 

jJavax.script javax.security.auth javax.security.auth.callback 
javax.security.auth.login|javax.security.auth.spi javax.security.auth.spi 
jJavax.security.auth.x500 | javax.security.cert 

Compact profile 2: 


javax.xml.transform.stream] javax.xml.validation javax.xml.xpath 


org.w3c.dom.bootstrap org.w3c.dom.events 
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Compact profile 3: 


java.lang.instrument 


java.lang.management 


java.security.acl 


java.util.prefs javax.annotation.processing|javax.lang.model 
javax.lang.model.element javax.lang.model.type javax.lang.model.util 
javax.management javax.management.loading javax.management .modelmbean 
javax.management.monitor javax.management.openmbean | javax.management.relation 
javax.management.remote javax.management.remote.rmi | javax.management.timer 
javax.naming javax.naming.directory javax.naming.event 
javax.naming.ldap javax.naming.spi javax.security.auth.kerberos 
javax.security.sasl javax.sql.rowset javax.sql.rowset.serial 
javax.sql.rowest.spi javax.tools javax.xml.crypto 
javax.xml.crypto.dom javax.xml.crypto.dsig javax.xml.crypto.dsig.dom 
javax.xml.crypto.dsig.keyinfo]|]javax.xml.crypto.dsig.spec |org.ieft.jgss 


The three compact module profiles represent the basis for the standardized modular system 
in Java 9. The effectiveness of this standardization relies on the following six principles: 


All JCP-governed modules must start with the string java.. So, if a module on 


spatial utilities was being developed it would have a name such as 
java.spatial.util. 


JCP refers to the Java Community Process. JCP allows developers to 
create technical specifications for Java. You can learn more about JCP and 
become a member at the official JCP website--http://www.jcp.org. 


the string jdk.. 


the following flowchart: 


Non-JCP modules are considered part of the JDK and their names must start with 


Ensure method invocation chaining works properly. This is best illustrated with 
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Does 
module 
export a 
package? 


Design Principle 
#3 


Does 
package 
contain a 

public 
member? 


Does 
package 
contain a 
protected 
member? 


Is there a 
type 
reference 
from 
another 
module? 


The first module must 
implement public access to 
second module. 


As you can see in the preceding flowchart, it only applies to modules that 
export a package. 
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e The fourth principle deals with both standard and non-standard API packages 
being used in a standard module. The following flowchart illustrates the 
implementation of this principle's covenants: 


Is exported 
API Export may be 
rele d eared 
standard? 


Design Principle 
#4 


Export must be Export must be to a 
ualified module that is in 
a the JDK 


e The fifth design principle is that standard modules can be dependent upon more 
than one non-standard module. While this dependency is permitted, implied 
readability access to non-standard modules is not. 

e The final design principle ensures non-standard modules do not export standard 
API packages. 


Modularizing JDK source code [JEP-201] 


As previously mentioned, Project Jigsaw had the goal of modularization. The envisioned 
standard modular system would be applied to the Java SE platform and the JDK. In 
addition to efficiency gains, the modular shift would result in better security and ease 
maintainability. The enhancement detailed in JEP-201 focused on JDK source code 
reorganization. Let's take a closer look. 


[ 68 ] 


www.EBooksWorld.ir 


Building Modular Applications with Java 9 


Reorganizing the JDK's source code is a significant task and was accomplished with the 
following subset of goals: 


e Provide JDK developers insights and familiarity with the new Java 9 modular 
system. So, this goal was aimed at developers of the JDK, not mainstream 
developers. 

e Ensure modular boundaries are established and maintained throughout the JDK 
build process. This was a necessary precaution so the modular system would be 
stable throughout Java 9's enhancements and, more specifically, in implementing 
the modular system. 

e The third goal was to ensure future enhancements, specifically with Project Jigsaw, 
could be easily integrated into the new modular system. 


The significance of this source code reorganization cannot be overstated. The pre-Java 9 
source code organization is 20 years old. This overdue JDK source code reorganization will 
make the code much easier to maintain. Let's look at the previous organization of the JDK 
source code and then examine the changes. 


Pre-Java 9 JDK source code organization 


The JDK is a compilation of code files, tools, libraries, and more. The following illustration 
provides an overview of the JDK components: 


dev 
= JavaFX Tools ~ 


source 


code 


oe 
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The pre-Java 9 organization of the JDK components in the preceding illustration are 
detailed in the next seven subsections. 


Development tools 


The development tools are located in the \bin directory. These tools include seven broad 
categorizations, each detailed in the subsequent sections. 


Deployment 


This is a set of tools intended to help deploy Java applications: 


appletviewer: This tool gives you the ability to run and debug Java applets 
without the need for a web browser. 

extcheck: This tool allows you to find conflicts in JAR files. 

jar: This tool is used for creating and manipulating JAR files. JAR files are Java 
Archive files. 

java: This is the Java application launcher. 

javac: This is the Java Compiler. 

javadoc: This tool generates API documentation. 

javah: This tool allows you to write native methods; it generates C header files. 
javap: This tool disassembles class files. 

javapackager: For signing and packaging Java applications, including JavaFX. 
jdb: This is the Java debugger. 


jdeps: This is an analyzer for Java class dependencies. 

pack200: This is a tool that compresses JAR files into pack200 files. The 
compression ratio using this tool is impressive. 

unpack200: This tool unpacks pack200 files resulting in JAR files. 


Internationalization 


If you are interested in creating localizable applications, the following tool might come in 


handy: 


native2ascii: This tool creates Unicode Latin-1 from normal text. 
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Monitoring 


Monitoring tools used for providing JVM performance data include: 


e jps: This is the JVM process status tool (jps). It provides a list of HotSpot JVMs 
on a specific system. 

e jstat: This is the JVM statistics monitoring tool. It collects log data and 
performance information from a machine with a HotSpot JVM. 


e jstatd: This is the jstat daemon tool. It runs an RMI server app for monitoring 
HotSpot JVM operations. 


RMI 


RMI tools are Remote Method Invocation tools. They help developers create applications 
that operate over a network to include the internet: 


e rmic: This tool can generate stubs and skeletons for objects over a network 
e rmiregistry: This is a registry service for remote objects 

e rmid: This tool is an activation system daemon for RMI 

e serialver: This tool returns the class serialVersionUID value 


Security 


This set of security tools empowers developers to create security policies that can be 
enforced on the developer's computer system as well as on remote systems: 


e keytool: This tool manages security certificates and keystores 

e jarsigner: This tool generates and verifies JAR signatures for creating/opening 
JAR files 

e policytool: This tool has a graphical user interface that helps developers 
manage their security policy files 


Troubleshooting 
These experimental troubleshooting tools are useful for very specific troubleshooting. They 
are experimental and, therefore, not officially supported: 


e jinfo: This tool provides configuration information for specific processes, files, 
or servers. 
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jhat: This is a heap dump tool. It instantiates a web server so that a heap can be 
viewed with a browser. 

jmap: This displays heap and shared object memory maps from a process, file, or 
server. 

jsadebuga: This is Java's Serviceability Agent Debug Daemon. It acts as a debug 
server for a process or file. 

jstack: This is a Java Stack Trace tool that provides a thread stack trace for a 
process, file, or server. 


Web services 
This set of tools provides a utility that can be used with Java Web Start and other web 


services: 


javaws: This is a command line tool that launches Java Web Start. 

schemagen: This tool generates schemas for Java architecture. These schemas are 
used for XML binding. 

wsgen: This tool is used for generating JAX-WS artifacts that are portable. 
wsimport: This tool is used for importing portable JAX-WS artifacts. 

xjc: This is the binding compiler that is used for XML binding. 


JavaFX tools 


The JavaFX tools are located in a few different places including \bin, \man, and \lib 
directories. 


Java runtime environment 


The Java runtime environment (JRE) is located in the \jre directory. Key contents include 
the Java Virtual Machine (JVM) and class libraries. 


Source code 


The JDK's source code, pre-Java 9, has the following basic organizational schema: 


source code / [shared, OS-specific] / [classes / native] / Java API 


package name / [.file extension] 
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Let's look at this a bit closer. After the source code, we have two options. If the code is cross- 
platform, then it is a shared directory; otherwise, it is operating system specific. For 
example: 


src/share/... 
src/windows/... 


Next, we have the classes directory or a native language directory. For example: 


src/share/classes/... 
src/share/classes/java/... 


Next, we have the name of the Java API package followed by the file extension. The file 
extensions depend on content such as . java, .c, and more. 


Libraries 


The \1ib directory houses class libraries that are needed by one or more of the 
development tools in the \bin directory. Here is a list of files in a typical Java 8 \lib 
directory: 


E Command Prompt 
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Reviewing the directory listing does not provide a great level of granular insight. We can 
list the classes contained in any of the . jar files with the following command--jar tvf 
fileName. jar. As an example, here is the class listing generated from executing jar tvf 
javafx-mx. jar at the command line: 


E Command Prompt 


ð Mon 
Mon 
Ə Mon 
Mon 
Mon 
Mon 
Mon 
Mon 
Mon 5 816 o j j m JSONDocum 


Mon 


Mon 


Mon 


o 
o 
o 


OOOO 
W-E- 
w 


oo 


Mon 


Mon 


C 


) 


Mon 


C 


T 


Mon 
6 Mon 


Mon 


[s] 


Mon 
Mon 


NANDN|ANDA 
o 


Mon 


AO 


Mon 
Mon 


C header files 


The /include directory contains C header files. These files primarily support the 
following: 


e Java Native Interface (JNI): This is used for native-code programming support. 
The JNI is used to embed Java native methods and the JVM into native apps. 

e JVM Tool Interface (JVM TI): This is used by tools for state inspections and 
execution control for apps running the JVM. 
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Database 


The Apache Derby relational database is stored in the /db directory. You can learn more 
about Java DB at the following sites: 


http://docs.oracle.com/javadb/support/overview. html 


http://db.apache.org/derby/manuals/#docs_10.11 


JDK source code reorganized 


In a previous section, you learned that the pre-Java 9 source code organization schema was 
as follows: 


source code / [shared, OS-specific] / [classes / native] / Java API 
package name / [.file extension] 


In Java 9, we have a new modular schema. That schema follows: 


source code / module / [shared, OS-specific] / [classes / native / 
configuration] / [ package / include / library ] / 
[.file extension] 


There are a few differences in the new schema, most notably the module name. After the 
shared or OS-specific directory, there is either the classes directory, the native directory for 
C or C++ source files, or a configuration directory. This seemingly rudimentary organization 
schema changes results in a much more maintainable code base. 


Understanding modular run-time images 
[JEP-220] 


Java 9's modular system required changes to the runtime images for compatibility. Benefits 
of these changes include enhancements in the following areas: 


e Maintainability 
e Performance 
e Security 
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Core to these changes was a new URI schema used for resource naming. These resources 
include modules and classes. 


Resource Locator) in that it identifies the name and location of something. 


A Uniform Resource Identifier (URI) is similar to a URL (Uniform 
gp For a URL, that something is a web page; for a URI, it is a resource. 


There were five primary goals for JEP-220 and these are detailed in the following sections. 


Runtime format adoption 


A run-time format was created for Java 9, for adoption by stored classes and other resource 
files. This format is applicable for stored classes and resources under the following 
circumstances: 


e When the new run-time format has greater efficiencies (time and space) than the 
pre-Java 9 JAR format. 


A JAR file is a Java ARchieve file. This is a compressed file format based 
i on the legacy ZIP format. 


e When stored classes and other resources can be individually isolated and loaded. 

e When JDK and library classes and resources can be stored. This includes app 
modules as well. 

e When they are devised in such a way as to promote future enhancements. This 
requires them to be extensible, documented, and flexible. 


Runtime image restructure 


There are two types of runtime images in Java--JDK and JRE. With Java 9, both of these 
image types were restructured to differentiate between files that can be used and modified 
by users to internal files that can be used but not modified by developers and their apps. 
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The JDK build system, prior to Java 9, produces both a JRE and a JDK. The JRE is a complete 
implementation of the Java platform. The JDK includes the JRE as well as other tools and 
libraries. A notable change in Java 9 is that the JRE subdirectory is no longer part of the JDK 
image. This change was made, in part, to ensure both image types (JDK and JRE) have 
identical image structures. With a common and reorganized structure, future changes will 
be more efficiently integrated. 


If you created custom plugins prior to Java 9 that address a specific 
structure, your app might not work in Java 9. This is also true if you are 
explicitly addressing tools. jar. 


The following diagram provides a high-level view of the contents of each image before Java 
9's release: 


JRE Image JDK Image 


e bin e jre 

e lib e bin 

+ demo 
e sample 
* man 

* include 
e lib 


The Java 9 runtime images are illustrated in the following diagram. As shown, a full JDK 
image contains the same directories as a modular runtime image as well as demo, sample, 
man, and includes directories: 


Modular RunTime Full JDK Image 
Image 

e bin e bin 

e conf * conf 

e lib e lib 
e demo 
e sample 
* man 
¢ include 


There is no longer a difference between a JRE or JDK image. Now, with Java 9, a JDK image 
is a JRE image that contains a full set of dev tools. 
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Supporting common operations 


Developers occasionally must write code that performs operations requiring access to the 
runtime image. Java 9 includes support for these common operations. This is possible due 
to the restructuring and standardized JDK and JRE runtime image structures. 


De-privileging JDK classes 


Java 9 allows privilege revocation for individual JDK classes. This change strengthens 
system security in that it ensures JDK classes only receive the permissions required for 
system operations. 


Preserving existing behaviors 


The final goal of the JEP-220 was to ensure currently existing classes are not negatively 
impacted. This refers to applications that do not have dependencies on internal JDK or JRE 
runtime images. 


Getting to know the module system 
[JEP-261] 


The purpose of this JEP was the implementation of the new module system for the Java 
platform. You will recall that the modular system was created to provide reliable 
configuration and strong encapsulation for Java programs. Key to this implementation was 
the concept of link time. As illustrated here, link time is an optional phase in between 
compile time and runtime. This phase allows the assembly of the appropriate modules into 
an optimized runtime image. This is possible, in part, due to the jlink linking tool which you 
will learn more about later in this chapter: 
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Compile Time Run Time 


Module paths 


It is important to organize modules so that they can be easily located. The module path, a 
sequence of module components or directories, provides the organizational structure used 
by searches. These path components are searched for in order, returning the first path 
component that comprises a module. 


Modules and their paths should not be considered to be the same as packages or class 
paths. They are indeed different and have a greater level of fidelity. The key difference is 
that, with classpaths, a singular component is searched for. Module path searches return 
complete modules. This type of search is possible by searching the following paths, in the 
presented order, until a module is returned: 


e Compilation module path 
e Upgrade module path 

e System modules 

e Application module path 


Let's briefly review each of these paths. The compilation module path is only applicable at 
compile time and contains the module definitions. The upgrade module path has the 
compiled module definitions. The system modules are built-in and include Java SE and JDK 
modules. The final path, the application module path, has the compiled module definitions 
from the application modules as well as the library modules. 
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Access-control boundary violations 


As a professional developer, you always want your code to be secure, portable, and bug- 
free, which requires strict adherence to Java constructs such as encapsulation. There are 
occasions, such as with white box testing, that you need to break the encapsulation that the 
JVM mandates. This mandate permits cross-modular access. 


To permit breaking the encapsulation, you can add an add-exports option in your module 
declaration. Here is the syntax you will use: 


module com.three19.irisScan 

{ 
- -— add-exports <source-module>/<package> = <target-module> 
(, <target-module> )* 


} 


Let's take a closer look at the preceding syntax. The <source-module> and <target- 
module> are module names and <package> is the name of the package. Using the add- 
exports option permits us to violate access-control boundaries. 


There are two rules regarding using the add-exports option: 


e It can be used multiple times in a module 


e Each use must be of a unique pairing of <source-module> and <target- 
module> 


It is not recommended that the add-exports option be used unless 
absolutely necessary. Its use permits dangerous access to a library 
module's internal API. This type of use makes your code dependent on the 
internal API not changing, which is beyond your control. 


Runtime 


The HotSpot virtual machine implements the <options> for the jmod and jlink 
command-line tools. Here is the list of <options> for the jmod command-line tool: 
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Applications with J 


Command Prompt 


C:\Program Files\Java\jdk-9\bin>jmod --help 
Usage: jmod (create|extract|list|describe|hash) <OPTIONS> <7jmod-file> 


Main operation modes: 


create - 
extract - 
list - 
describe 
hash 


Option 
--class-path 
--cmds <path 
--config <pa 
--dir <path> 


--dry-run 
--exclude <p 


-h, --help 


Creates a new jmod archive 

Extracts all the files from the archive 
Prints the names of all the entries 
Prints the module details 

Records hashes of tied modules. 


Description 


<path> Application jar files|dir containing 
classes 
> Location of native commands 
th> Location of user-editable config files 
Target directory for extract 
Dry run of hash mode 
attern-list> Exclude files matching the supplied 
comma separated pattern list, 
element using one the following 
forms: <glob-pattern>, glob:<glob- 
pattern> or regex:<regex-pattern> 
Print this usage message 


--hash-modules <regex-pattern> Compute and record hashes to tie a 


packaged module with modules 
matching the given <regex-pattern> 
and depending upon it directly or 
indirectly. The hashes are recorded 
in the JMOD file being created, or a 
JMOD file or modular JAR on the 
module path specified the jmod hash 
command. 


--header-files <path> Location of header files 


--help-extra 


Print help on extra options 


--legal-notices <path> Location of legal notices 
--libs <path> Location of native libraries 


--main-class 


<class-name> Main class 


--Man-pages <path> Location of man pages 


--module-ver 
-p, --module 


--version 
@<filename> 


sion <module-version> Module version 
-path <path> Module path 


Target platform 
Version information 
Read options from the specified file 


C:\Program Files\Java\jdk-9\ 
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Here is the list of <options> for the j1ink command-line tool: 


Command Prompt 


--launct <name>=<module 


--limit-modules <mod>[ ,<mod> 


Modular Java application packaging 
[JEP-275] 


One of the great improvements in Java 9 is the size of the runtime binaries generated by the 
Java Packager. This is possible in part due to the Java Linker, which is covered in the next 
section. The Java Packager's workflow has essentially remained the same in Java 9 as it was 
in Java 8. There have been, as you will see later in this section, new tools added to the 


workflow. 
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The Java Packager solely creates JDK 9 applications. This change to the Java Packager is 
intended to streamline and make the process of generating runtime images more efficient. 
So, the Java Packager will only create runtime images for the SDK version that it is 
associated with. 


Advanced look at the Java Linker 


Prior to the Java Linker tool, jlink, introduced in Java 9, runtime image creation included 
copying the entire JRE. Then, unused components are removed. Simply put, j1ink 
facilitates the creation of runtime images with only the required modules. j1ink is used by 
the Java Packager to generate an embedded runtime image. 


Java Packager options 
The syntax for the Java Packager is as follows: 


javapackager -command [-options] 


There are five different commands (—command) that can be used. They are described as 
follows: 


~createbss | This command is used for converting files from CSS to binary 


—createjar | This command, used along with additional parameters, creates a JAR archive 
file 


-deploy This command is used to generate jnlp and HTML files 
-makeall Combines the -createjar, -deploy, and compilation steps 
-signJar This command creates and signs a JAR file 
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The [-options] for the -createbss command include: 


-outdir <dir> 
name of the directory to generate 
-srcdir <dir> 
Base dir of the 
-srcfiles <files> 
List of files in srcdir. If omitted, a files i (which 
is I y argument in this ca 


-appclass <application 
qualified name 
-preloader <preloader cla 
qualified name of 
-paramfile <file> 
properties file with default named application parameters. 
-argument arg 
An unnamed argument to be put in <fx:argument> element in the JNLP 
file. 
-classpath <files> 
list of dependent jar file names. 
festAttrs <manifest attributes> 
List of additional manifest attributes. Syntax: “namei=valuel, 
name2=value2,name3=value3. 
-noembedlauncher 
will not add the JavaFX launcher classes 


files to binary form before copying 


-runtimeversion <version> 
version of the required JavaFX Runtime. 
-outdir <dir> 
name of the directory to generate output file to. 
-outfile <filename> 
The name (without the extension) of the resulting file. 
-srcdir <dir> 
Base dir of the files to pack. 
-srcfiles <files> 
List of files in srcdir. If omitted, all files in srcdir (which 
is a mandatory argument in this case) will be packed. 
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The [-options] for the -deploy command include: 


-native <type> 
generate self-contained application bundle 
If type is specified then only bundle of this type is : 
List of supported types includes: installer, image, ex i, dr ok rpm, de 
-name <name> 
name of the application. 
-appclass <application class> 
qualified name of the application class to be executed. 
-outdir <dir> 
name of the directory to generate output file to. 
-outfile <filename> 
The name (without the extension) of the resulting 
-srcdir <dir> 
Base dir of the files to pack. 
-srcfiles <files> 
ist of file n srcdir. If omit 11 files in srcdir (which 
a mandatory argument in this i 
ename>[/<maincla 
<modulename>[/<mainclass> 
initial module to re ve nd the name of the main class 
execute if not specified by e module 
-p <module lps 
--module-path <module path>... 
A : separated list of di 
is a directory of modules. 
--add-modules <modulename>[,<modulename>... ] 
root modules to resolve in addition to the initial module 
--limit-modules <modulename>[ ,<modulename>... ] 
limit the universe of observable modules 
--strip-native-commands <true/false> 
include or exclude the native commands 
-title <title> 
title of the application. 
-vendor <vendor> 
vendor of the application. 
-description <description> 
description of the application. 
-embedjnip 
If present, the jnlp file will be embedded in the html document. 
-embedCertificates 
If present, e certificates will be embedded in the jnlp fi 
See icra 


A DN 


-m <mod 
u 


= -mod 


rectories, each directory 


lication will require all security permissions 


he 
Þe 
— D 

v D 
. Q 
pe] 
wv 


-updatemode < bile ony 
sets the update mode for the jnlp file 

-isExtension 
if present, ] 5 i are treated as extensions. 
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Here are the remaining [-options] for the -deploy command: 


i HTML. The format is 


are in form of 

#XXXX. YYYY (APPID)# 
-templateOutFilename 

name of the html file to write the filled-in template to. 
-temp eld 

Application ID of the applic 
-argument arg 

An unnamed argument to be put in <fx:argument> element in the JNLP 


on for template processing. 


-preloa 
preloader cla 
-paramfi 


-html mfile <file> 
properties file with parameters 
<width> 
width of the application. 
<height> 
height of the application. 


-appclass <application class> 
qualified name 
-preloader <preloader class> 
name of 
-cl iles> 
list j 
-name <name> 
name 
-width <width> 
width of the applicati 
-height <height> 
height of 
enable ver 


he application. 
ose output. 


t 
b 
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The [-options] for the -signJar include: 


The Java Packager is divided into two modules: 


jdk.packager 
jdk.packager.services 


JLink - The Java Linker [JEP-282] 


The Java Linker, commonly referred to as JLink, is a tool that was created to create custom 
runtime images. This tool collects the appropriate modules along with their dependencies, 
then optimizes them to create the image. This represents a big change for Java, with the 
release of Java 9. Before the Java Linker tool, j1ink, was available, runtime image creation 
included initially copying the entire JRE. In a subsequent step, the unused components 
were removed. In Java 9, j1ink creates runtime images with only the needed modules. 
jlink is used by the Java Packager to generate an embedded runtime image. 


As illustrated in a previous section, JEP-282 resulted in link time as an optional phase 
between compile time and runtime. It is in this phase that the appropriate modules are 
assembled into an optimized runtime image. 


JLink is a command-line linking tool that permits the creation of runtime images containing 
a smaller subset of the JDK modules. This results in smaller runtime images. The following 
syntax consists of four components--the j 1ink command, options, the module path, and 
the output path: 


$ jlink <options> ---module-path <modulepath> --output <path> 
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Here is a list of the options that can be used with the j1ink tool along with brief 
descriptions of each: 


Ge Command Prompt 


Program Fi \ dk-9\bin>jlink --help 
jlink ath <modulepath> --add-modules <module>[,<module>... 


Constant 


--launcher <name> 


of 


--limit-modules < 


given file 
t implement the 
from the module path 
ing 


ys from 


:\Program Fi 


The module path tells the linker where to find the modules. The linker will not use 
exploded modules or JAR/JMOD files. 


The output path simply informs the linker where to save the custom run-time image. 
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Encapsulating most internal APIs [JEP-260] 


JEP-260 was implemented to make the Java platform more secure. The core of this JEP's goal 
was to encapsulate the majority of internal APIs. Specifically, most of the JDK's internal 
APIs are no longer accessible by default. Currently, internal APIs deemed to be critical and 
widely-used remain accessible. In the future, we are likely to see functionality to replace 
them, and at that time, those internal APIs will not be accessible by default. 


So, why is this change necessary? There are a few widely-used APIs that are unstable and, 
in some cases, not standardized. Unsupported APIs should not have access to internal 
details of the JDK. Therefore, JEP-260 resulted in increased security of the Java platform. 
Generally speaking, you should not use unsupported APIs in your development projects. 


The aforementioned critical APIs (internal to the JDK) are: 


èe sun.misc 
e sun.misc.Unsafe 
e sun.reflect.Reflection 


èe sun.reflect.ReflectionFactory.newConstrutorForSerialization 


The aforementioned critical internal APIs are still accessible in JDK 9. They will be 
accessible with the jdk . unsupported JDK module. Full JRE and JDK images will contain 
the jdk. unsupported module. 


You can use the Java Dependency Analysis Tool, jdeps, to help determine 
if your Java program has any dependencies on JDK internal APIs. 


This is an interesting change to watch. It is likely that the currently accessible internal APIs 
will not be accessible by default when Java 10 is released. 
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Summary 


In this chapter, we examined the structure of Java modules as specified by Project Jigsaw and 
took an in-depth look at how Project Jigsaw was implemented to improve the Java platform. 
We also reviewed key internal changes to the Java platform as they relate to the modular 
system. Our review started with a modular primer where we learned about Java 9's 
modular system in terms of benefits and requirements. 


We explored how Java 9 introduced modularity to the JDK including its source code and 
organization of the same. The seven primary tool categories that make up the JDK were also 
explored. As we learned, modularity in Java 9 also extends to runtime images resulting in 
more maintainability, better performance, and increased security. The concept of link time 
was introduced as an optional phase between compile-time and runtime. We concluded the 
chapter with a look at the Java Linker and how Java 9 encapsulates internal APIs. 


In the next chapter, we will explore how to migrate our existing applications to the Java 9 
platform. We will look at both manual and semi-automated migration processes. 


[90 ] 


www.EBooksWorld.ir 


Migrating Applications to Java 9 


In the previous chapter, we took a close look at the structure of Java modules as specified by 
Project Jigsaw and examined how Project Jigsaw was implemented to improve the Java 
platform. We also reviewed key internal changes to the Java platform with specific focus on 
the new modular system. We started with a modular primer where we learned about Java 
9's modular system in terms of benefits and requirements. Next, we explored how Java 9 
introduced modularity to the JDK. This included a look at how the source code was 
reorganized for Java 9. We also explored the JDK's seven primary tool categories and 
learned that Java 9 modularity extends to runtime images resulting in more maintainability, 
better performance, and increased security. The concept of link time was introduced as an 
optional phase between compile-time and runtime. We concluded the chapter with a look at 
the Java linker and how Java 9 encapsulates internal APIs. 


In this chapter, we will explore how to migrate our existing applications to the Java 9 
platform. We will look at both manual and semi-automated migration processes. Java 9 is a 
major release with numerous changes to the JDK so developers should not be surprised if 
their Java 8 code no longer works with Java 9. This chapter aims to provide you with 
insights and processes to get your Java 8 code working with Java 9. 


The topics we will cover in this chapter are: 


e Quick review of Project Jigsaw 

e How modules fit into the Java landscape 
e Migration planning 

e Advice from Oracle 

e Useful tools 
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Quick review of Project Jigsaw 


Project Jigsaw is the Java project that encompasses several change recommendations to the 
Java platform. As you have read in earlier chapters, Java 9's greatest changes involve 
modules and modularity. The initiative to move to modules in Java was driven by Project 
Jigsaw. The need for modularity stemmed from two major challenges with Java: 


e Classpath 
e JDK 


Next, we will review both of those challenges and see how they were addressed and 
overcome with the new release to the Java platform, Java 9. 


Classpath 


Prior to Java 9, the classpath was problematic and the source of developer anguish. This 
was evident in the numerous developer forums and, fortunately, Oracle was paying 
attention. Here are the several instances in which the classpath can be problematic; here are 
two primary cases: 


e The first case involves having two or more versions of a library on your 
development computer. The way this was previously handled by the Java system 
was inconsistent. Which library was used during the class loading process was 
anyone's guess. This resulted in an undesired lack of specificity--not enough 
details regarding which library was loaded. 


The second case is in exercising the most advanced features of the class loader. 
Often times, this type of class loader usage resulted in the most errors and bugs. 
These were not always easy to detect and resulted in a lot of extra work for 
developers. 


Classpaths, before Java 9, were almost always very lengthy. Oracle, in a recent presentation, 
shared a classpath that contained 110 JAR files. This type of unwieldy classpath makes it 
difficult to detect conflicts or even determine if anything was missing and if so, what might 
be missing. The re-envisioning of the Java platform as a modular system made these 
classpath issues a thing of the past. 


Modules solve the pre-Java 9 classpath problem by providing reliable 
configuration. 
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The monolithic nature of the JDK 


Java has continually evolved in an impressive fashion since 1995 and with each 
evolutionary step, the JDK grew larger. As with Java 8, the JDK had become prohibitively 
large. Prior to Java 9, there were several problematic issues stemming from the monolithic 
nature of the JDK, including: 


Because the JDK is so large, it does not fit on very small devices. In some 
development sectors this is enough reason to find a non-Java solution for 
software engineering problems. 

The oversized JDK resulted in waste. It was wasteful in terms of processing and 
memory when running on devices, networks, and the cloud. This stems from the 
fact that the entire JDK is loaded, even when only a small subset of the JDK is 
required. 

While the Java platform has great performance when running, the startup 
performance, in terms of load and launch times, leaves much to be desired. 

The vast number of internal APIs has also been a pain point. Because so many 
internal APIs existed and were used by developers, the system has been difficult 
to evolve. 

The existence of internal APIs has made it difficult to make the JDK secure and 
scalable. With so many internal dependencies, isolating security and scalability 
issues has been overly problematic. 


The answer to the monolithic woes of the JDK is the module. Java 9 introduced the module 
and its own modular system. One of the great updates to the platform is that only the 
modules needed are compiled, as opposed to the entire JDK. This modular system is 
covered throughout this book. 


Modules solve the pre-Java 9 JDK monolithic issue by providing strong 
encapsulation. 
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How modules fit into the Java landscape 


As you can see from the following illustration, packages are comprised of classes and 
interfaces, and modules are comprised of packages. Modules are a container of packages. 
This is the basic premise, at a very high level, of Java 9's new modular system. It is 
important to view modules as part of the modular system and not simply as a new level of 
abstraction above packages, as the illustration might suggest. 


module 


class interface 


So, modules are new to Java 9 and they, as you would expect, require declaration before 
they can be used. A module's declaration includes names of other modules in which it has a 
dependency. It also exports packages for other modules that have dependencies to it. 
Modular declarations are arguably the most important modular issue to address as you 
start developing with Java 9. Here is an example: 


module com.three19.irisScan 


{ 
// modules that com.three19.irisScan depends upon 
requires com.three19.irisCore; 
requires com.three19.irisData; 


// export packages for other modules that are dependent 
upon com.three19.irisScan 
exports com.three19.irisScan.biometric; 


} 


When programming a Java 9 application, your module declarations will be placed in a 
module-info. java file. Once this file is completed, you simply run javac, the Java 
Compiler, to generate the module-info.class Java class file. You accomplish this task in 
the same manner that you currently compile your . java files into .class files. 


You can also create modular JAR files that have your module-info.class file at its root. 
This represents a great level of flexibility. 
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Base module 


When programming Java 9 applications, or porting existing applications programmed with 
older versions of Java, the base module (java.base) must be used. Every module requires 
the java.base module because it defines the critical, or foundational, Java platform APIs. 
Here are the contents of the java. base module: 


module java.base 


{ 


exports java.io; 

exports java.lang; 

exports java.lang.annotation; 
exports java.lang.invoke; 
exports java.lang.module; 
exports java.lang.ref; 

exports java.lang.reflect; 
exports java.math; 

exports java.net; 

exports java.net.spi; 

exports java.nio; 

exports java.nio.channels; 
exports java.nio.channels.spi; 
exports java.nio.charset; 
exports java.nio.charset.spi; 
exports java.nio.file; 

exports java.nio.file.attribute; 
exports java.nio.file.spi; 
exports java.security; 

exports java.security.aci; 
exports java.security.cert; 
exports java.security.interfaces; 
exports java.security.spec; 
exports java.text; 

exports java.text.spi; 

exports java.time; 

exports java.time.chrono; 
exports java.time.format; 
exports java.time.temporal; 
exports java.time.zone; 

exports java.util; 

exports java.util.concurrent; 
exports java.util.concurrent.atomic; 
exports java.util.concurrent.locks; 
exports java.util.function; 
exports java.util.jar; 

exports java.util.regex; 

exports java.util.spi; 
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exports java.util.stream; 

exports java.util.zip; 

exports java.crypto; 

exports java.crypto.interfaces; 
exports java.crytpo.spec; 

exports java.net; 

exports java.net,ssi; 

exports java.security.auth; 
exports java.security.auth.callbak; 
exports java.security.auth.login; 
exports java.security.auth.spi; 
exports java.security.auth.x500; 
exports java.security.cert; 


} 


As you can see, the java.base module does not require any modules and it exports 
numerous packages. It can be useful to have a list of these exports handy so you know what 
is available to you as you start creating applications using the new Java platform, Java 9. 


You will notice that in the previous section, we did not include the requires java.base; 
line of code in our declaration of our com. three19.irisScan module. The updated code 
is provided as follows and now includes the requires java.base; line of code: 


module com.three19.irisScan 

{ 
// modules that com.three19.irisScan depends upon 
requires java.base; // optional inclusion 
requires com.three19.irisCore; 
requires com.three19.irisData; 


// export packages for other modules that are dependent 
upon com.three19.irisScan 
exports com.three19.irisScan.biometric; 


} 


If you do not include the requires java.base; line of code in your module declarations, 
the Java Compiler will automatically include it. 


Reliable configuration 


As suggested earlier in this chapter, modules provide a reliable configuration of our Java 9 
applications that solves the classpath problem in earlier versions of the Java platform. 
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Java reads and interprets modular declarations making the modules readable. These 
readable modules permit the Java platform to determine if any modules are missing, if there 
are duplicate libraries declared, or there are any other conflicts. In Java 9, very specific error 
messages will be generated and output by the compiler or at runtime. Here is an example of 
a compile-time error: 


src/com.three19.irisScan/module-info.java: error: module not found: 
com.three19.irisScan 
requires com.three19.irisCore; 

a 


1 error 


Here is an example of a runtime error that would occur if the module 
com.three19.isrisCore was not found, but required by the com.three19.irisScan 


app: 


Error occurred during initialization of VM 
java.lang.module.ResolutionException: Module com.three19.irisCore not 
found, required by com.three19.irisScan app 


Strong encapsulation 


Earlier in this chapter, you read that Java 9's strong encapsulation remedied the monolithic 
JDK issue. Encapsulation, in Java 9, is driven by the information in the module-info. java 
file. The information in this file lets Java know what modules are dependent upon others 
and what each of them exports. This underscores the importance of ensuring our module- 
info-java files are properly configured. Let's look at an example written with standard 
Java code, nothing new in Java 9 in the way this was coded: 


com.three19.irisScan com.three19.access 
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In the preceding example, the com. three19.irisScan module has an irisScanner 
package intended for internal use and an irisScanResult class. If the 
com.three19.access application tries to import and use the irisScanResult class, the 
following error message will be produced by the Java Compiler: 


src/com.three19.access/com/three19/access/Main.java: error: irisScanResult 
is not accessible because package com.three19.irisScanner.internal is not 
exported 


private irisSanResult scan1 = new irisScanResult () ; 
a 


1 error 


If for some reason the compiler does not catch this error, although it would be very 
unlikely, the following runtime error would occur: 


Exception in thread "main" java.lang.IllegalAccessError: class 
com.three19.access.Main (in module: com.three19.access) cannot access class 
com.three19.irisScanner.internal.irisScanResult (in module: 
com.three19.irisScan), com.three19.irisScanner.internal is not exported to 
com.three19.access. 


The detailed error messages will make debugging and troubleshooting much easier. 


Migration planning 


The changes to the Java platform are significant and Java 9 is considered a major release. It 
would be naive to think our current Java applications will work seamlessly on Java 9. While 
that might be the case, at least for simple programs, it is prudent to plan ahead and consider 
the issues you are most likely to encounter. Before we look at these issues, let's test a simple 
Java application in the next section. 


Testing a simple Java application 


The following code consists of a single Java class, GeneratePassword. This class prompts 
the user for a desired password length and then generates a password based on the user's 
requested length. If the user asks for a length shorter than 8, the default length of 8 will be 
used. This code was written with the Java SE 1.7 JRE System Library: 


/* 
* This is a simple password generation app 


7 
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import java.util.Scanner; 


public class GeneratePassword 
{ 
public static void main(String[] args) 
{ 
// passwordLength int set up to easily change the schema 
int passwordLength = 8; //default value 


Scanner in = new Scanner (System.in); 
System.out.printin("How long would you like your 
password (min 8)?"); 

int desiredLength; 

desiredLength = in.nextInt(); 


// Test user input 
if (desiredLength >8) 
{ 
passwordLength = desiredLength; 


// Generate new password 
String newPassword = createNewPassword (passwordLength) ; 


// Prepare and provide output 
String output = "\nYour new " + passwordLength 
+ "-character password is: "; 


System.out.println(output + newPassword) ; 


public static String createNewPassword(int lengthOfPassword) 
{ 

// Start with an empty String 

String newPassword = ""; 


// Populate password 
for (int i = 0; i < lengthOfPassword; i++) 
{ 
newPassword = newPassword + randomizeFromSet ( 
"aAbBcCdDeEfFgGhHiljJkK1LmMnNoOpPqQrRsSt TuUvVwWxXyYzZ 
0123456789+-*/?!@#SS&") ; 


return newPassword; 


public static String randomizeFromSet (String characterSet) 


{ 
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int len = characterSet.length(); 
int ran = (int) (len * Math.random()); 
return characterSet.substring(ran, ran + 1); 


} 


In the following screenshot, we test the GeneratePassword app ona Mac running Java 8. 
As you can see, we start by querying Java to verify the current version. In this test, Java 
1.8.0_121 was used. Next, we compile the GeneratePassword Java file using the javac 
utility. Lastly, we run the app: 


eee A edljr — -bash — 80x24 


Edwards-iMac:~ edljr$ java -version 

java version "1.8.0_121" 

Java(TM) SE Runtime Environment (build 1.8.@_121-b13) 

Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) 
Edwards—iMac:~ edljr$ 

Edwards-iMac:~ edljr$ 

Edwards-iMac:~ edljr$ javac GeneratePassword. java 
Edwards-iMac:~ edljr$ 
Edwards-iMac:~ edljr$ 
Edwards-iMac:~ edljr$ java GeneratePassword 
How long would you like your password (min 8)? 
32 


Your new 32-character password is: B#CZy@z1MqQWI@dkFfiuG9BrHw$w9KFg 
Edwards-iMac:~ edljr$ I 


As you can see from the preceding test, GeneratePassword. java was successfully 
compiled with the GeneratePassword.class file resulting. The application was run using 
the java GeneratePassword command. The user was prompted for a desired password 
length and 32 was entered. The application then successfully generated a 32-character 
random password and provided the appropriate output. 


This test demonstrated the example application works successfully using JDK 1.8. Next, let's 
test the same application using JDK 9. 
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We start with the java -version command to show that we are using JDK 9 on this 
computer. The following screenshot shows that we successfully compiled the . java file toa 
.class file. When the application was run, it functioned as expected and provided the 
proper results: 


E Command Prompt 


As you can see, we clearly demonstrated that a pre-Java 9 application has the potential to 
successfully run on Java 9 without having to make any modifications. This is a simple case 
study and featured a very basic Java program. This is, of course, the best case scenario, and 
cannot be assumed. You will want to test your applications to ensure they run as expected 
on the Java 9 platform. 


In the next section, we will review some potential issues you might encounter when testing 
your pre-Java 9 applications using the new Java platform with JDK 9. 


Potential migration issues 


The potential migration issues featured in this section include direct access to the JRE, 
access to internal APIs, accessing internal JARs, JAR URL depreciation, the extension 
mechanism, and the JDK's modularization. Let's look at each of these potential migration 
issues. 


[101] 


www.EBooksWorld.ir 


Migrating Applications to Java 9 


The JRE 


Creating the Java 9's modular system resulted in some simplification in respect to the 
number and location of development and utility tools. One such example is the JDK's 
consumption of the JRE. In all pre-Java 9 versions, the Java platform included the JDK and 
JRE as two separate components. In Java 9, these components have been combined. This is a 
significant change and one that developers should be keenly aware of. If you have an 
application that specifically points to the JRE directory, you will need to make changes to 
avoid problems. The JRE contents are shown as follows: 


D Javaviwwelachines © D jdk1.8.0_121jdk » Into plist COPYRIGHT COPYRIGHT 
E jdk1.8.0.131 joe » n 


RTYUCENSEREADME- JAVAFX txt 
UCENSEREADME txt 
mi 


sre.zip 
THIRDPARTYLICENSEREADME-JAVAFX.txt 
THIROPARTYLICENSEREADME txt 


Access to internal APIs 


The Java 9 platform has encapsulated internal APIs to increase security of the platform and 
applications written in Java. Applications that you program in Java 9 will not have default 
access to the JDK's internal APIs, unlike with previous versions of the Java platform. Oracle 
has identified some internal APIs as critical; those APIs remain accessible via the 
jdk.unsupported JDK module. 


The aforementioned critical APIs (internal to the JDK) are: 


e sun.misc 
èe sun.misc.Unsafe 
e sun.reflect.Reflection 


e sun.reflect.ReflectionFactory.newConstrutorForSerialization 
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If you have pre-Java 9 applications that implement any sun. * or com.sun.* package, you 
will likely run into problems migrating your applications to Java 9. In order to address this 
issue, you should review your class files for use of sun. * and com. sun. * packages. 
Alternatively, you can use the Java dependency analysis tool, jdeps, to help determine if 
your Java program has any dependencies on JDK internal APIs. 


The jdeps tool is the Java dependency analysis tool, that can be used to 
help determine if your Java program has any dependencies on JDK 
internal APIs. 


Accessing internal JARs 


Java 9 does not permit access to internal JARs such as 1ib/ant-javax. jar, lib/dt. jar, 
and others listed in the 1ib directory shown here: 


= ant-javafx.jar 
ct.sym 
æ dt.jar 
ir.idl 
= javafx-mx.jar 
æ jconsole.jar 


™ missioncontrol 
orb.idl 

= packager.jar 

æ sa-jdijar 

= tools.jar 

™ visualvm 


The key thing to note here is that if you have Java applications that are dependent on one of 
these tools residing in the 1ib folder, you will need to modify your code accordingly. 


It is recommended that you test your IDE once you start using Java 9 to 
ensure the IDE is updated and officially supports Java 9. If you use more 
than one IDE for Java development, test each one to avoid surprises. 
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JAR URL depreciation 


JAR file URLs were, prior to Java 9, used by some APIs to identify specific files in the 
runtime image. These URLs contain a jar: file: prefix with two paths; one to the jar and 
one to the specific resource file within the jar. Here is the syntax for the pre-Java 9 JAR 
URL: 


jar: file:<path-to-jar>!<path-to-file-in-jar> 


With the advent of Java 9's modular system, containers will house resource files instead of 
individual JARs. The new syntax for accessing resource files is as follows: 


jrt:/<module-name>/<path-to-file-in-module> 


A new URL schema, jrt, is now in place for naming resources within a runtime image. 
These resources include classes and modules. The new schema allows for the identification 
of a resource without introducing a security risk to the runtime image. This increased 
security ensures that the runtime image's form and structure remain concealed. Here is the 
new schema: 


jxrt:/[SMODULE[/SPATH] ] 


Interestingly, a jrt URL's structure determines its meaning, suggesting that the structure 
can take one of several forms. Here are three examples of different j rt URL structures: 


e jrt:/$MODULE/ $PATH: This structure provides access to the resource file, 
identified with the $PATH parameter, within the module specified with the 
SMODULE parameter 

e jxt:/SMODULE: This structure provides reference to all resource files within the 
module specified with the $MODULE parameter 


e jrt:/: This structure provides reference to all resource files in the runtime image 


If you have preexisting code that uses URL instances, returned by APIs, you should not 
have any problems. On the other hand, if your code is dependent on the jar URL structure, 
you will have problems. 
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Extension mechanism 


The Java platform previously had an extension mechanism that gave developers the ability 
to make custom APIs available to all applications. As you can see in the following 


illustration, extensions are plugins of sorts, or add-ons to the Java platform. The APIs and 
classes in each extension are, by default, automatically available: 


Java Application 


Equal Access 


Extension! 
Extension 


m Extension 


As the illustration suggests, Java applications have access both to the Java platform and 


extensions without requiring classpaths. This feature was depreciated in Java 8 and no 
longer exists in Java 9. 
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The JDK's modularization 


By now, you have a firm appreciation of Java 9's modularization. The old adage in Java, and 
other object-oriented programming language, is everything is a class. Now, with Java 9, 
everything is a module is the new adage. There are three type of modules as explained as 
follows: 


Automatic When a JAR is placed on a new module path, modules are automatically 
created 


Explicit/Named | These modules are manually defined by editing the module-info. java file 
When a JAR is placed on a classpath, unnamed modules are created 


When you migrate your applications to Java 9, your application and its libraries become 
unnamed modules. So, you will need to ensure all the modules are in the module path. 


Another thing to be aware of is that your runtime image will not contain the entire JDK. 
Instead, it will only contain the modules your application requires. It is worth reviewing 
how the JDK is modularized in Java 9. The following table contains the API specification for 
the JDK in Java 9: 


k.accessibility jdk.attach jdk.charsets jdk.compiler 


-crypto.cryptoki jdk.crypto.ec j .dynalink jdk.editpad 


-hotspot.agent jdk.httpserver j .incubator.httpclient |jdk.jartool 


.javadoc jdk.jcmd j .jconsole jdk.jdeps 


Jai jdk.jdwp.agent jdk.jlink jdk.jshell 


.jsobject jdk.jstatd jdk.localedata jdk.management 


d jd 
a 


jdk.scripting.nashorn]jdk.sctp j 


k.security.auth jdk.security.jgss 


jdk.snmp jdk.xml.dom jdk.zipfs 
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The following table contains the API specification for Java SE in Java 9: 


java.activation java.base java.compiler java.cobra 
java.datatransfer |java.desktop java.instrument J 
java.management java.management.rmi|java.naming j 


.rmi scripting .se j .se. ee 


.security.jgss security.sasi .sql j .sql.rowset 


.transaction xml .xml.bind j .xml.crypto 


.xml.ws xml.ws .xml.ws.annotation 


Remember, all applications will have access to java . base as it is in the 
module path by default. 


The following table contains the API specification for JavaFX in Java 9: 


javafx.controls|javafx.fxml|javafx.graphics 


There are two additional modules: 


e java. jnlp defines the API for JNLP (Java Network Launch Protocol) 
e java.smartcardio defines the API for the Java Smart Card Input/Output 


For details on any of these modules, visit Oracle's Java® Platform, Standard 
Edition & Java Development Kit Version 9 API Specification website: http: // 


download. java.net/java/jdk9/docs/api/overview-summary.html. 


Advice from Oracle 


Oracle has done a great job in bringing us this major update, version 9, to the Java platform. 
Their insights into getting ready for Java 9 and how to migrate to the new JDK is worth 
reviewing. In this section, we will look at preparatory steps, breaking encapsulation, 
changes to the runtime image, components such as tools and APIs that have been removed, 
changes to garbage collection, and deployment. 
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Preparatory steps 


Oracle provides a five-step process to help developers migrate their Java applications to 
version 9. These steps are listed as follows and then covered in subsequent sections: 


1. Get the JDK 9 early access build. 

2. Run your program before recompiling. 
3. Update third-party libraries and tools. 
4. Compile your application. 

5. Run jdeps on your code. 


Getting the JDK 9 early access build 


If you are reading this book before Java 9 is officially released, then you can obtain a JDK 9 
early access build from here--ht tp: //jdk.java.net/9/. Early release builds are available 
for Windows (32 and 64), macOS (64), Linux (32 and 64) and various Linux ARM, Solaris, 
and Alpine Linux versions. 


Taking the time to test your applications for Java 9 and get them migrated before Java 9 is 
officially released, helps ensure you will not experience any downtime for services that rely 
on your Java applications. 


Running your program before recompiling 


As indicated earlier in this chapter, there is a chance that your existing Java applications 
will run without modification on the Java 9 platform. So, before you make any changes, try 
running your current application on the Java 9 platform. If your application works fine on 
Java 9, that is great, but your work is not complete. Review the next three sections on 
updating third-party libraries and tools, compiling your application, and running jdeps on 
your code. 


Updating third-party libraries and tools 


Third-party libraries and tools can help extend our applications and shorten development 
time. For Java 9 compatibility, it is important to ensure that each third-party library and tool 
you use is compatible with and supports version 9 of the JDK. Running your application on 
Java 9 will not provide you with the level of insight you need to ensure you do not have 
compatibility issues down the road. It is recommended that you review the official website 
for each library and tool to verify compatibility with and support of JDK 9. 
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If a library or tool that you use does have a version that supports JDK 9, download and 
install it. If you find one that does not yet support JDK 9, consider finding a replacement for 
it. 


In our context, tools includes Integrated Development Environments (IDE). NetBeans, 
Eclipse, and IntelliJ all have IDE versions that support JDK 9. Links to those sites are 
provided as follows: 


e NetBeans: http: //bits.netbeans.org/download/trunk/nightly/latest/ 


° Eclipse: https: //www.eclipse.org/community/ clipse_newsletter/2015/june/ 
article4.php 


e IntelliJ: https: //www.jetbrains.com/idea/nextversion/ 


Compiling your application 

Your next step is to compile your application using JDK 9's javac. This is important, even if 
your app works fine on JDK 9. You might not receive compiler errors, but watch for 
warnings too. Here are the most common reasons your applications might not compile with 
JDK 9, assuming they compiled fine prior to Java 9. 


First, as indicated earlier in this chapter, most of the JDK 9 internal APIs are not accessible 
by default. Your indication will be an IllegalAccessErrors error at runtime or compile 
time. You will need to update your code so that you are using accessible APIs. 


A second reason your pre-Java 9 applications might not compile with JDK 9 is if you use the 
underscore character as a single character identifier. According to Oracle, this practice 
generates a warning in Java 8 and an error in Java 9. Let's look at an example. The following 
Java class instantiates an Object named _ and prints a singular message to the console: 


public class Underscore 
{ 
public static void main(String[] args) 
{ 
Object _ = new Object (); 
System.out.printin("This ran successfully."); 


} 
} 
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When we compile this program with Java 8, we receive a warning that use of '_' as an 
identifier might not be supported in releases after Java SE 8: 


eee A edljr — -bash — 80x9 


Edwards-iMac:~ edljr$ javac Underscore. java 
Underscore.java:6: warning: '_' used as an identifier 
Object _ = new Object(); 


(use of '_' as an identifier might not be supported in releases after Java SE 


8) 
1 warning 
Edwards-iMac:~ edljr$ 


As you can see in the following screenshot, that is just a warning and the application runs 


fine: 


eee A edljr — -bash — 46x5 


Edwards-iMac:~ edljr$ java Underscore 
This ran successfully. 
Edwards—-iMac:~ edljr$ 


Now, let's try compiling the same class using JDK 9: 


E Command Prompt 
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As you can see, use of the underscore as a single character identifier still only resulted in a 
warning and not an error. The application ran successfully. This test was run when JDK 9 
was still in early release. It is assumed that running this test once JDK 9 has been officially 
released will result in an error instead of just a warning. The error that would likely be 
thrown is as follows: 


Underscore.java:2: error: as of release 9, '_' is a keyword, and may not be 
used as a legal identifier. 


Even if this issue is not resolved with the formal release of JDK 9, use of an underscore as a 
single character identifier is not good programming practice, so you should steer away from 
using it. 


A third potential reason for your pre-Java 9 programmed application not to compile with 
JDK 9 is if you are using the -source and -target compiler options. Let's take a look at 
the -source and -target compiler options pre-Java 9 and with Java 9. 


Pre-Java 9 -source and -target options 


The -source option specifies the Java SE version and has the following acceptable values: 


javac does not support features introduced after Java SE 1.3 
javac accepts code with language features introduced in Java SE 1.4 
1. j 


javac accepts code with languages features introduced in Java SE 1.5. 


6 or 6 | javac reports encoding errors as errors instead of warnings. Of note, no new 
language features were intruded with Java SE 1.6. 


javac accepts code with language features introduced in Java SE 1.7. This is the 


default value if the -source option is not used. 
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The -target option tells javac what version of the JVM to target. The acceptable values 
for the -target option are--1.1,1.2,1.3,1.4,1.50r5,1.6o0r6 and 1.7 or 7. If the - 
target option is not used, the default JVM target is dependent on the value used with the - 
source option. Here is a table of -source values with their associated -target: 


default -target 


Java 9 -source and -target options 


In Java 9, the supported values are shown as follows: 


Supported values | Remarks 
This is the default, should no value be specified 
Sets support to 1.8 


Sets support to 1.6 and generates a warning (not an error) to indicate JDK 6 
is depreciated 


Seco 


Running jdeps on your code 


The jdeps class dependency analysis tool is not new to Java 9, but perhaps has never been 
as important to developers with the advent of Java 9. An important step to migrating your 
applications to Java 9 is to run the jdeps tool to determine the dependencies your 
applications and its libraries have. The jdeps tool does a great job of suggesting 
replacements if your code has dependencies on any internal APIs. 
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The following screenshot shows the options available to you when using the jdeps 
analyzer: 


§ Command Prompt 


file, 


e options i 


aumuvuvge 


Uv 


a. 


e 


nput 
pti 
WARNING: JDK 
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Let's take a look at an example. Here is a simple Java class called DependencyTest: 


import sun.misc.BASE64Encoder; 


public class DependencyTest 
{ 
public static void main(String[] args) throws 
InstantiationException, IllegalAccessException 
{ 
BASE64Encoder.class.newInstance(); 
System.out.printin("This Java app ran successfully."); 


} 


Now, let's use javac to compile this class using Java 8: 


B 
Edwards-iMac:~ edljr$ javac DependencyTest. java 
DependencyTest.java:1: warning: BASE64Encoder is internal proprietary API and may be 
removed in a future release 
import sun.misc.BASE64Encoder; 


Aa 


DependencyTest.java:6: warning: BASE64Encoder is internal proprietary API and may be 


removed in a future release 
BASE64Encoder.class.newlnstance(); 

2 warnings 

Edwards—iMac:~ edljr$ java DependencyTest 

This Java app ran successfully. 

Edwards—iMac:~ edljr$ 


As you can see, Java 8 successfully compiled the class and the application ran. The compiler 
did give us a DependencyTest.java:6: warning: BASE64Encoder is internal 


proprietary API and may be removed in a future release warning. Now, let's 
see what happens when we try to compile this class using Java 9: 


E Command Prompt 
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In this case, with Java 9, the compiler gave us two warnings instead of one. The first 
warning is for the import sun.misc.BASE64Encoder; statement and the second for the 
BASE64Encoder.class.newInstance(); method call. As you can see, these are just 
warnings and not errors, so the DependencyTest . java class file is successfully compiled. 
Next, let's run the application: 


E Command Prompt 


Now, we can clearly see that Java 9 will not allow us to run the application. Next, let's run a 
dependency test using the jdeps analyzer tool. We will use the following command line 
syntax--jdeps DependencyTest.class: 


Ge Command Prompt 


As you can see, we have three dependencies: java.io, java.lang, and sun.misc. Here 
we are given the suggestion to replace our sun.misc dependency with rt. jar. 


Breaking encapsulation 


The Java 9 platform is more secure than its predecessor versions due to, in part, the 
increased encapsulation that resulted from the modular reorganization. That being said, 
you might have a requirement to break through the modular system's encapsulation. 
Breaking through these access control boundaries is permitted by Java 9. 
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As you read earlier in this chapter, most internal APIs are strongly encapsulated. As 
previously suggested, you might look for replacement APIs when updating your source 
code. Of course, that is not always feasible. There are three additional approaches you can 
take--using the --add-opens option at runtime; employing the --add-exports option; 
and --permit-illegal-access command-line option. Let's look at each of those options. 


The --add-opens option 


You can use the --add-opens runtime option to allow your code to access non-public 
members. This can be referred to as deep reflection. Libraries that do this deep reflection are 
able to access all members, private and public. To grant this type of access to your code, you 
use the --add-opens option. Here is the syntax: 


--add-opens module/package=target-—module(,target-module) * 


This allows the given module to open the specified package. The compiler will not produce 
any errors or warnings when this is used. 


The --add-exports option 


You can use -~add-exports to break encapsulation so that you can use an internal API 
whose default is to be inaccessible. Here is the syntax: 


--add-exports <source-module>/<package>=<target-—module> ( 
,<target—module>) * 


This command-line option gives code in the <target —module> access to types in the 
<source-module> package. 


Another method of breaking encapsulation is with a JAR file's manifest. Here is an example: 


—-add-exports:java.management/sun.management 


The --add-exports command-line option should only be used if deemed 
absolutely necessary. It is not advisable to use this option except for short- 
term solutions. The danger of using it routinely is that any updates to 
referenced Internal APIs could result in your code not working properly. 
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The --permit-illegal-access option 


A third option for breaking encapsulation is to use the --permit-—illegal-access option. 
Of course, it is prudent to check with third-party library creators to see if they have an 
updated version. If that is not an option, you use --permit-illegal-access to gain 
illegal access to operations to be implemented on the classpath. Due to the significantly 
illegal operation here, you will receive warnings each time one of these operations occurs. 


Runtime image changes 


Java 9 represents a major change to the JDK and the JRE. Much of these changes are related 
to modularity and have been covered in other chapters. There are still a few more things 
you should consider. 


Java version schema 


With Java 9, the way the Java platform's version is displayed has changed. Here is an 
example of a pre-Java 9 version format: 


Last login: Sat Jul 15 15:04:45 on ttys000 
Edwards-iMac:~ edljr$ java -version 


java version "1.8.0_121" 

Java(TM) SE Runtime Environment (build 1.8.0_121-b13) 

Java HotSpot(T) 64-Bit Server VM (build 25.121-b13, mixed mode) 
Edwards-iMac:~ edljr$ 


Now, let's look at how Java 9 reports its version: 


Eï Command Prompt 


As you can see, with Java 9, the version schema is now 

SMAJOR. $MINOR. $SECURITY. $PATCH. This is markedly different than with previous 
versions of Java. This will only impact your applications if you have code that parses the 
string returned by the java -version command and option. 
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JDK and JRE layout 


How files are organized in the JDK and the JRE have changed in the new version of Java. It 
is worth your time to familiarize yourself with the new filesystem layout. The following 
screenshot shows the file structure of the JDK's /bin folder: 
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Here is the layout of the \1ib folder: 


GE Command Prompt - dir /s/w/p 
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What has been removed 


Another area of change for the new version of the Java platform is that many platform 
components have been removed. The following sections represent the most significant 
components. 


Notably, the rt . jar and tools. jar and dt. jar have been removed. These JAR files 
contained class and other resources files and all resided in the /1ib directory. 


The endorsed standards override mechanism has been removed. In Java 9, both javac and 
java will exit if they detect that mechanism. The mechanism was used for application 
servers to override some JDK components. In Java 9, you can use upgradeable modules to 
achieve the same result. 


As previously covered in this chapter, the extension mechanism has also been removed. 


The following listed APIs were previously depreciated and have been removed and are not 
accessible in Java 9. Removal of these APIs is the result of the modularization of the Java 
platform: 


e apple.applescript 

e com.apple.concurrent 

e com.sun.image.codec. jpeg 

e java.awt.dnd.peer 

e java.awt.peer 

e java.rmi.server.disableHttp 

e java.util.logging.LogManager.addPropertyChangeListener 


e java.util.logging.LogManager.removePropertyChangeListener 


e java.util.jar.Pack200.Packer.addPropertyChangeListener 


e java.util.jar.Pack200.Packer.removePropertyChangeListener 


e java.util.jar.Pack200.Unpacker.addPropertyChangeListener 


e java.util.jar.Pack200.Unpacker.removePropertyChangeListener 


e javax.management.remote.rmi.RMII1IOPServerImpl 


e sun.misc.BASE64Encoder 


e sun.misc.BASE64Decoder 


e sun.rmi.transport.proxy.connectTimeout 
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e sun.rmi.transport.proxy.eagerHttpFallback 
e sun.rmi.transport.proxy.logLevel 


e sun.rmi.transport.tcp.proxy 


The following listed tools have been removed. In each case, the tool was previously 
depreciated or its functionality superseded by better alternatives: 


e hprof 

e jJava-rmi.cgi 
e jJava-rmi.exe 
e JavaDB 

e jhat 


e native2ascii 


Two additional things that have been removed in Java 9 are: 


e AppleScript engine. This engine was deemed as unusable and is dropped 
without replacement. 

e Windows 32-bit client virtual machine. JDK 9 does support a 32-bit server JVM, 
but not a 32-bit client VM. This change was made to focus on the increased 
performance of 64-bit systems. 


Updated garbage collection 


Garbage collection has been one of Java's great claims to fame. In Java 9, the Garbage-First 
(G1) garbage collector is now the default garbage collector on both 32- and 64-bit servers. In 
Java 8, the default garbage collector was the parallel garbage collector. Oracle reports that 
there are three garbage collection combinations that will prohibit your application from 
starting in Java 9. Those combinations are: 


e DefNew + CMS 
e Incremental CMS 
e ParNew + SerialOld 


We will take an in-depth look at Java 9 garbage collection in chapter 7, Leveraging the New 
Default G1 Garbage Collector. 
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Deployment 


There are three issues that you should be aware of, in the context of migrating to Java 9, 
when you are deploying your applications. These issues are JRE version selection, serialized 
applets, and the update to the JNLP. 


JNLP is the acronym for Java Network Launch Protocol and is covered in 
a a later section of this chapter. 


JRE version selection 


Prior to Java 9, developers could request a JRE version other than the version being 
launched when launching an application. This could be accomplished with a command-line 
option or with a proper JAR file manifest configuration. This feature has been removed in 
JDK 9 because of the way we typically deploy applications. Here are the three primary 
methods: 


e Active installers 
e Java Web Start using JNLP 
e Native OS packaging systems 


Serialized applets 


Java 9 does not support the ability to deploy applets as serialized objects. In the past, 
applets were deployed as serialized objects to compensate for slow compression and JVM 
performance issues. With Java 9, compression techniques are advanced and the JVM has 
great performance. 


If you attempt to deploy your applets as serialized objects, your object attributes and 
parameter tags will simply be ignored when your applet launches. Starting with Java 9, you 
can deploy your applets using standard deployment strategies. 
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JNLP update 


The JNLP is used for launching applications on a desktop client using resources located on 
a web server. JNLP clients include Java Web Start and Java Plug-in software because they 
are able to launch applets that are remotely hosted. This protocol is instrumental in 
launching RIAs. 


RIAs are Rich Internet Applications and when launched with JNLP have access to the 
various JNLP APIs that, with user permission, can access the user's desktop. 


In Java 9, the JNLP specification has been updated. There are four specific updates as 
detailed in the next sections. 


Nested resources 


The ability to use component extensions with nest resources in Java or j2se elements was 
previously supported, but not documented in the specification. The specification has now 
been updated to reflect this support. The previous specification read: 


No java elements can be specified as part of the resources. 
The updated specification for Java 9 now reads: 


A java element in a component extension will not govern what version of java is used, but 
may be used containing nested resource elements, and then those resources may be used 
only when using a Java version that matches the given version as specified in section 4.6 


This specific change ensures that extension JLP files must have java or j2se resources and 
those resources will not dictate what JRE is used. Nested resources are permitted when 
using the specified version. 


FX XML extension 
When using the JNLP, you create a JNLP file. Here is an example: 
<?xml version="1.0" encoding="UTEF-8"?> 
<jnlp spec="1.0+" codebase="" href=""> 
<information> 


<title>Sample/title> 
<vendor>The Sample Vendor</vendor> 
<icon href="sample-icon.jpg"/> 
<offline-allowed/> 

</information> 

<resources> 
<!-- Application Resources --> 
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<j2se version="1.6+" 
href="http://java.sun.com/products/autodl/j2se"/> 
<jar href="Sample-Set.jar" main="true" /> 
</resources> 
<application-desc 
name="Sample Application" 
main-class="com.vendor.SampleApplication" 
width="800" 
height="500"> 
<argument >Arg1</argument> 
<argument >Arg2</argument> 
<argument >Arg3</argument> 
</application-desc> 
<update check="background"/> 
</jnlp> 


Two changes have been made to the <application-desc> element. First, the optional 
type attribute has been added so the type of application can be annotated. The default type 
is Java, so if your program is a Java app, you need not include the type attribute. 
Alternatively, you can specify Java as your type as follows: 


<application-desc 
name="Another Sample Application" 
type="Java" main-class="com.vendor.SampleApplication2" 
width="800" 
height="500"> 
<argument>Arg1</argument> 
<argument>Arg2</argument> 
<argument>Arg3</argument> 
</application-desc> 


We can indicate other application types to include JavaFX as shown here: 


<application-desc 
name="A Great JavaFX Application" 
type="JavaFX" main-class="com.vendor.GreatJavaFXApplication" 
width="800" 
height="500"> 
<argument>Arg1</argument> 
<argument>Arg2</argument> 
<argument>Arg3</argument> 
</application-desc> 


If you indicate an application type that is not supported by the JNLP 
client, your application launch will fail. For more information about JNLP, 
you can consult the official documentation: http: //docs.oracle.com/ 
javase/7/docs/technotes/guides/javaws/developersguide/faq.html. 
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The second change to the <application-desc> element in Java 9 is the addition of the 
param sub-element. This allows us to provide the name of parameters along with their 
value using the value attribute. Here is an example of how an <application-desc> 
element of a JNLP file looks with the param sub-element and the value attribute included. 
This example shows three sets of parameters: 


<application-desc 
name="My JRuby Application" 
type="JRuby" 
main-class="com.vendor.JRubyApplication" 
width="800" 
height="500"> 
<argument>Arg1</argument> 
<argument>Arg2</argument> 
<argument>Arg3</argument> 
<param name="Parameter1" value="Valuei"/> 
<param name="Parameter2" value="Value2"/> 
<param name="Parameter3" value="Value3"/> 
</application-desc> 


If the application type is Java, then any param sub-elements you use will 
be ignored. 


JNLP file syntax 


JNLP file syntax is now in complete compliance with XML specifications. Prior to Java 9, 
you could use & to create complex comparisons. That is not supported with standard XML. 
You can still create complex comparisons in JNLP files. Now you will use &amp; instead of 
&. 


Numeric version comparison 


The JNLP specification has been changed to reflect how numeric version elements were 
compared against non-numeric version elements. Previous to the change, version elements 
were compared lexicographically by ASCII value. With Java 9 and this JNLP specification 
change, elements are still compared lexicographically by ASCII value. The change is evident 
when the two strings have different lengths. In new comparisons, the shorter string will be 
padded with leading zeros to match the length of the longer string. 
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Lexicographical comparisons use a mathematical model that is based on 
alphabetical order. 


Useful tools 


The first thing you will need to do before migrating your applications to Java 9 is to 
download JDK 9. You can download the early access builds at this URL--http://jdk. java. 
net /9/. You will need to accept the license agreement and then select which build to 
download. As you can see in the following screenshot, there are several options based on 


your operating system: 


Windows 


Mac OS 
Linux 


Linux ARM 


Solaris SPARC 
Solaris x86 


Alpine Linux 


Now that you have JDK 9 installed on your development computer, let's look at a couple of 


JRE 

exe (sha256) 83.59 MB 
exe (sha256) 88.62 MB 
dmg {sha256) 72.28 MB 
tar.gz (sha256) 77.95 MB 
tar.gz (sha256) 78.96 MB 


tar.gz (sha256) 52.26 MB 
tar.gz (sha256) 51.94 MB 


Server JRE 


tar.gz (sha2s6) 200.00 MB 


JDK 

exe {sha256) 298.30 MB 
exe (sha256) 309.18 MB 
dmg (sha256) 319.94 MB 
tar.gz (sha256) 271.22 MB 
tar.gz (sha256) 279.76 MB 
tar.gz (sha256) 176.19 MB 
tar.gz (sha256) 176.06 MB 
tar.gz (sha256) 206.72 MB 
tar.gz (sha256) 205.77 MB 


JDK 
tar.gz (sha256) 200.00 MB 


tools that can help facilitate migrating your applications to Java 9. 
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Java environment - jEnv 


If you develop on a computer with Linux or macOS, you might consider using jEnv, an 
open source Java environment management tool. This is a command-line tool, so do not 
expect a GUI. You can download the tool at this URL--https: //github.com/gcuisinier/ 


jenv. 
Here is the installation command for Linux: 
$ git clone https://github.com/gcuisinier/jenv.git ~/.jenv 
To download using macOS with Homebrew, use this command: 
$ brew install jenv 
You can also install on Linux or macOS using Bash as follows: 


$ echo 'export PATH="S$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile 
$ echo 'eval "$(jenv init -)"' >> ~/.bash_profile 


Alternatively, you can install on Linux or macOS using Zsh as follows: 


$ echo 'export PATH="SHOME/.jenv/bin:$PATH"' >> ~/.zshre 
$ echo 'eval "$(jenv init -)"' >> ~/.zshre 


After you have jEnv installed, you will need to configure it on your system as shown here. 
You will need to modify the script to reflect your actual path: 


$ jenv add /Library/Java/JavaVirtualMachines/jdk17011.jdk/Contents/Home 


You will want to repeat the jenv add command for each version of the JDK on your 
system. With each jenv add command, you will receive confirmation that the specific JDK 
version was added to jEnv as follows: 


$ jenv add /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home 
oracle64-1.6.0.39 added 

$ jenv add /Library/Java/JavaVirtualMachines/jdk17011.jdk/Contents/Home 
oracle64-1.7.0.11 added 


You can check to see what JDK versions you have added to your jEnv by using $ jenv 
versions at the Command Prompt. This will result in an output list. 
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Here are three additional j Env commands: 


e jenv global <version>: this sets the global version 
e jenv local <version>: this sets the local version 
e jenv shell <version>: this sets the instance version for the shell 


Maven 


Maven is an open source tool that can be used for building and managing Java-based 
projects. It already supports Java 9 and is part of the Apache Maven Project. If you are not 
already using Maven and you do a lot of Java development you might be enticed by the 
following Maven objectives: 


e Making the build process easy 

e Providing a uniform build system 

e Providing quality project information 

e Providing guidelines for best practices development 
e Allowing transparent migration to new features 


You can read more specifics about each of the Maven objectives at this site--https://maven. 
apache. org/what-—is-maven.html. To download Maven, visit this site--https://maven. 
apache. org/download.cgi. Installation instructions for Windows, macOS, Linux, and 
Solaris are available here--https://maven.apache.org/install.html. 


Maven can be integrated with Eclipse (M2Eclipse), JetBrains IntelliJ IDEA, and the Netbeans 
IDE. The M2Eclipse IDE, as an example, provides rich integration with Apache Maven and 
boasts the following features: 


e You can launch Maven builds from within Eclipse 


Manage your dependencies for the Eclipse build path 


Easily resolve Maven dependencies (you can do this directly from Eclipse and not 
have to install a local Maven repository) 


Automatically download required dependencies (from remote Maven 
repositories) 


Use software wizards to create new Maven projects, create pom. xml files, and to 
enable Maven support for your plain Java projects 


Rapid dependency search of Maven remote repositories 
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Obtaining the M2Eclipse IDE 


To obtain the M2Eclipse IDE, you must first have Eclipse installed. Here are the steps: 


1. Start by opening your current Eclipse IDE. Next, select Preferences | 
Install/Update | Available Software Sites as shown in the following screenshot: 


Available Software Sites 
> General 
> Ant 


» Code Recommenders type filter text 


> Help Name ^a Location 

¥ Install/Update v al Mars http://download.eclipse.org/releases/mars 

v a Mylyn for Eclipse Mars http://download.eclipse.org/mylyn/releases/mars 
v a The Eclipse Project Updates http://download.eclipse.org/eclipse/updates/4.5 


Automatic Updates 
Available Software Sites 

> Java 

> Maven 

> Mylyn 

> Oomph 

> Run/Debug 

> Team 

Validation 
> WindowBuilder 


> XML Import... 


Cancel 
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2. The next task is to add the M2Eclipse repository site to your list of Available 
Software Sites. To accomplish this, click the Add button and enter values in the 
Name and Location text input boxes. For Name, enter something to help you 
remember that M2Eclipse is available at this site. For Location, enter the URL-- 
http://download.eclipse.org/technology/m2e/releases. Then, click the 


OK button: 


® Add Site 


Name: M2Eclipse Local... 


Location: l http://download.eclipse.org/technology/m2e/releases | Archive... 


3. You should now see the M2Eclipse site listed in your list of Available Software 
Sites as shown in the following screenshot. Your final step is to click the OK 
button: 


e o Preferences 


Available Software Sites 
» General 
> Ant 
> Code Recommenders 
> Help 
¥ install/Update 


Automatic Updates htt Naisa eclipse.org/re! saseannere 
Available Software Sites 3 iehi 


Soave | Mylyn for Eclipse Mars http://download.eclipse.org/mylyn/releases/mars 
> Maven Sİ] The Eclipse Project Updates http://download.eclipse.org/eclipse/updates/4.5 


type filter text 


Edit 


Remove 

> Mylyn 

> Oomph 

> Run/Debug 

> Team 
Validation Disable 

> WindowBuilder 

> XML Import. 


Reload 


Export. 


[130 ] 


www.EBooksWorld.ir 


Migrating Applications to Java 9 


4. Now, when you start a new project, you will see Maven Project as an option: 


Select a wizard 


Create a Maven Project 
Wizards: 


> C> General 

> (> Gradle 

> C> Java 

Y © Maven 
m- Check out Maven Projects from SCM 
M? Maven Module 


Ms Maven Project 
> (> Examples 


Cancel 


Maven is a proven tool for Java developers. You might consider obtaining additional 
information on Maven with one of the following resources: 


Apache Maven Project: https://maven.apache.org/index.html 


Apache Maven Cookbook: https: //www.packtpub.com/application-development/ 
apache-maven-—cookbook 


Apache Maven 3.0 Cookbook: https: //www.packtpub.com/application- 
development /apache-maven-3-cookbook 


Getting Started with Apache Maven [Video]: https: //www.packtpub.com/ 
application-development/getting-started-apache-maven-video 
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Summary 


In this chapter, we explored potential issues involved in migrating our existing applications 
to the Java 9 platform. We looked at both manual and semi-automated migration processes. 
This chapter provided you with insights and processes to get your Java 8 code working 
with Java 9. Specifically, we conducted a quick review of Project Jigsaw, looked at how 
modules fit into the Java landscape, provided tips for migration planning, shared advice 
from Oracle regarding migration, and shared tools that you can use to help you as you get 
started with Java 9. 


In the next chapter, we will take a close look at the Java shell and the JShell API. We 
demonstrate the JShell API and the JShell tool's ability to interactively evaluate declarations, 
statements, and expressions of the Java programming language. We will demonstrate 
features and use of this command-line tool. 
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In the previous chapter, we explored how to migrate pre-Java 9 applications to the new Java 
platform. We examined several issues that might cause your current applications to have 
problems running on Java 9. We started with a review of Project Jigsaw and then looked at 
how modules fit into the new Java platform. We provided you with insights and processes 
to get your Java 8 code working with Java 9. Specifically, we provided tips for migration 
planning, shared advice from Oracle regarding migration, and shared tools that you can use 
to help you as you get started with Java 9. 


In this chapter, we will take our first look at the new command line, read-eval-print loop 
(also referred to as REPL) tool in Java 9, the Java Shell (JShell). We will start with 
introductory information regarding the tool, the read-eval-print loop concept, and move 
into the commands and command-line options for use with JShell. We will take a 
practitioner's approach to our review of the Java Shell and include examples you can try on 
your own. 


The following topics are covered in this chapter: 


e What is JShell? 

e Getting started with JShell 
e Practical uses of JShell 

e Working with scripts 
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What is JShell? 


JShell is a new tool introduced with Java 9. It is an interactive read-eval-print loop tool that 
is used to evaluate the following Java programming language components--declarations, 
statements, and expressions. It has its own API so that it can be used by external 
applications. 


Read-Eval-Print Loop is often referred to as REPL, taking the first letter 
from each word in the phrase. It is also knows language shell or 
interactive top-level. 


The introduction of JShell was a result of Java Enhancement Program (JEP) 222. Here are 
the stated goals of this JEP in regards to the Java Shell command-line tool: 


e Facilitate rapid investigation 
e Facilitate rapid coding 
e Provide an edit history 


The rapid investigation and coding listed previously includes statements and expressions. 
Impressively, these statements and expressions do not need to be part of a method. 
Furthermore, variables and methods are not required to be part of a class, making this tool 
especially dynamic. 


In addition, the following listed features were included to make JShell much easier to use 
and to make your time using JShell as time-efficient as possible: 


e Tab-completion 

e Auto-completion for end-of-statement semicolons 
e Auto-completion for imports 

e Auto-completion for definitions 


Getting Started with JShell 


JShell is a command-line tool that is located in the /bin folder. The syntax for this tool is 
jshell <options> <load files>. As you can see here, there are several options that 
can be used with this tool: 
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use 


applicatio 
modules to r lve, < 1 modules on the 
module path if <module> l 
One run replacement f the 
run the 


-J<flag> 


-R<flag> 


DoD 


3 


Print 
Print version i yrmation 

Print this synopsis of standar 
Print help on non-standard options 


You have already seen the -h option, that we executed with jshe11 -h. This provided the 
listing of JShell options. 


To log into your JShell, you simply use the jshe11 command. You will see that the prompt 
in the command window changes accordingly: 


Command Prompt - jshell 


\Program Files\Java\j 


Welcome to JShell 
For an introduction 


hell> 
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Exiting the shell is as easy as entering /exit. Once inside the JShell, you can enter any of 
the following commands: 


Functionality 


/drop Use this command to delete a source entry that is referenced by name or id. 
Here is the syntax: 
/drop <name or id> 


/edit With this command, you can edit a source entry using a name or id reference. 
Here is the syntax: 
/edit <name or id> 


/env This powerful command allows you to view or change the evaluation context. 


Here is the syntax: 
/env [-class-path <path>] [-module-path <path>] 
[-add-modules <modules] 


/exit This command is used to exit the JShell. The syntax is simply /exit without 
any options or parameters available. 

/history |The history command provides a history of what you have typed. The syntax 
is simply /history without any options or parameters available. 


/<id> This command is used to rerun a previous snippet by referencing the id. Here 

is the syntax: /<id> 

You can also run a specific snippet by referencing the n" previous snippet with 
/-<n>. 


/imports | You can use this command to list the imported items. The syntax is /imports 
and it does not accept any options or parameters. 
/list This command will list the source you typed. Here is the syntax: 
/list [<name or id> | -all | -start] 
/methods | This command lists all declared methods as well as their signatures. Here is 


the syntax: 
/methods [<name or id> | -all | -start] 


/open Using this command, you can open a file as source input. Here is the syntax: 
/open <file> 


/reload |The reload command gives you the ability to reset and replay relevant history. 
Here is the syntax: 
/reload [-restore] [-quiet] [-class-path 
<path>] [-module-path <path>] 
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/reset |This command resets the JShell. Here is the syntax: 
/reset [-class-path <path>] [-module-path 
<path>] [-add-modules <modules] 
/save This command saves the snippet source to a file specified by you. Here is the 
syntax: 
/save [-all | -history | -start] <file> 


/set This command is used to set the JShell configuration information. Here is the 
syntax: 
/set editor | start | feedback | mode | prompt | 
truncation | format 


/types |This command simply lists declared types. Here is the syntax: 
/types [<name or id> | -all | -start] 
This command lists all declared variables as well as their values. Here is the 


syntax: 
/vars [<name or id> | -all | -start] 


This command will rerun the last snippet. The syntax is simply /! 


Several of the previously listed commands use the term snippet. In the 
context of Java 9 and JShell, a snippet is one of the following: 


- ClassDeclaration 

- Expression 

- FieldDeclaration 

- ImportDeclaration 


- InterfaceDeclaration 
- MethodDeclaration 


[ 137 ] 


www.EBooksWorld.ir 


Experimenting with the Java Shell 


Entering the /help or /? command in the JShell provides a complete list of commands and 
syntax that can be used in the shell. That list is provided as follows: 


Command Prompt - jshell 


declaration. 


cname or 


the 


/ name or id 


rop <name 


name or id 


urce input 
-all|-start] 
variab 


on| format 


re-run 
d> 
re-run snippet by id 
re-run n-th previo nippet 


on type '/help' followed by the name 


or ‘'/help intro’. 


ion to the jshel 
for snippet and comma completion, 
om code 


tions for /env /reload and 
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The /help command can be especially helpful if you are still new to JShell. As you can see 
in the following screenshot, we can obtain an introduction to JShell by simply entering the 
/help intro command: 


Command Prompt - jshell 


control w 


A 


For a list of command 


jshell> 


If you find yourself using JShell often you might benefit from one or more of the following 
listed shortcuts. These can be listed at any time from within JShell by using the /help 
shortcuts command: 


Command Prompt - jshell 


identifier, 
ommand argument, 


there is more than one 


show d mentation if í 
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Additional help can be obtained from within the JShell by using the /help command 
followed by the command you want additional help on. For example, entering /help 
reload provides detailed information regarding the /reload command. That information 
is provided as follows: 


E Command Prompt - jshell 


ode and execution nen replay h valid snippet 
the order € 


valid history 
command 


Practical uses of JShell 


Whether you are a new or seasoned developer or just new to Java, you are bound to find the 
JShell very useful. In this section, we will look at some practical uses of JShell. Specifically, 
we will cover: 


e Feedback modes 
e Listing your assets 
e Editing in the JShell 
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Feedback modes 


Command-line tools usually provide relatively sparse feedback in an effort to not 
overcrowd the screen or otherwise become a nuisance to developers. JShell has several 
feedback modes in addition to giving developers the ability to create their own custom 
modes. 


As you can see from the following screenshot, there are four feedback modes--concise, 
normal, silent, and verbose. Here, we entered the /set feedback command without 
any parameters to list the feedback modes as well as to identify what the current feedback 
mode is. The first line of output displays the command-line command and argument set 
that would be used to set the mode to the currently set mode. So, in the following 
screenshot, the current feedback mode is set to verbose and the other three modes are 
listed: 


E Command Prompt - jshell -v 


We can dictate which mode we want to enter when we first enter JShell by including an 
option when we launch JShell. Here are the command-line options: 


Command-line command and option | Feedback mode 


You will notice that we use -q for concise mode instead of -c. The -c option has the - 
c<flag> syntax and is used to pass <flag> to the compiler. 
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The best way to review the differences between the feedback modes is to use examples. 
Starting with the normal mode, we will execute command-line commands to accomplish 
the following ordered feedback demonstration: 


Create a variable. 

Update the variable's value. 
Create a method. 

Update the method. 

Run the method. 


Ol ae E a 


To start our first test, we will execute the /set feedback normal command at the 
jshell> prompt, which sets the JShell feedback mode to normal. After entering the 
normal feedback mode, we will enter the necessary commands to run our demonstration: 


EA Command Prompt - jshell 


m.out.printin our result 
however, it cannot be invoked 


tem.out.printin("Your result is " + (myVar*3@ + 19));} 


1N 
ath ) 
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After entering normal feedback mode, we entered int myVar = 3 toand received myVar 
==> 3 as feedback. In our next command, we changed the value of the same variable and 
received the same output with the new value. Our next statement, void quickMath () 
{System.out.printin("Your result is " + (x*30 + 19));}, used a variable that 
was not declared and you see the resulting two-part feedback--one part indicating that the 
method was created and the other to inform that the method cannot be invoked until the 
undeclared variable is declared. Next, we changed our method to include the myVar 
variable and the feedback reported that the method was modified. Our last step was to run 
the method using quickMath () ; and the results are as we expected. 


Let's try this same feedback demonstration in concise mode: 


Es Command Prompt - jshell 


As you can see from the preceding screenshot, the concise feedback mode provides us 
with much less feedback. We created and modified the variables and received no feedback. 
When we created the method with an undeclared variable, we received the same feedback 
that we did in normal mode. We updated the method without confirmation or other 
feedback. 
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Our next use of the feedback demonstration will be in silent mode: 


EA Command Prompt - jshell 


When we entered silent feedback mode, as you can see in the preceding screenshot, the 
JShell prompt changed from jshe11> to ->. There was no feedback provided when we 
created the myVar variable, modified the myVar variable, or created the quickMath () 
method. We intentionally created the quickMath () method to use an undeclared variable. 
Because we were in silent feedback mode, we were not informed that the method had an 
undeclared variable. Based on this lack of feedback, we ran the method and were not 
provided any output or feedback. Next, we updated the method to include the myVar 
declared variable and then ran the method. 


The silent feedback mode might seem pointless as no feedback is 
provided, but there is a great utility with this mode. Using the silent 
mode might be appropriate for pipelining or simply when you want to 
minimize the amount of terminal output. You can include specific, 
conditional, outputs with implicit System. out .print1n commands, as 
an example. 
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Our last use of the feedback demonstration is in verbose feedback mode. This feedback 
mode, as you would assume from its name, provides the most amount of feedback. Here 
are our test results: 


Gis Command Prompt - jshell 


e myVar : int 


nyVar 


tem.out 
however, it cannot be i 


m.out.println("Your result is " 


hod 


In our feedback demonstration, using verbose feedback mode, we receive a bit more 
feedback as well as a nicer format for the feedback. 
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Creating a custom feedback mode 


While the internal feedback modes (normal, concise, silent, and verbose) cannot be 
modified, you can create your own custom feedback mode. The first step in this process is 
to copy an existing mode. The following example demonstrates how to copy the verbose 
mode to a myCustom mode with the /set mode myCustom verbose -command 
command string: 


Command Prompt - jshell 


We used the -command option to ensure we would receive the command feedback. You can 
make various changes to your feedback mode using the /set command along with one of 
the options listed in the following screenshot: 


Command Prompt - jshell 


ing from an ing mode. 
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As an example, let's walk through the truncation setting that mandates how many 
characters are displayed on each output line. Using the /set truncation command, as 
illustrated in the following screenshot, shows the current truncation settings: 


E Command Prompt - jshell 


As you can see, our myCustom feedback mode has a truncation of 80. We will change that to 
60 with the /set truncation myCustom 60 command and then use the /set 
truncation command for verification: 


Command Prompt - jshell 


e 
e 
= 

se 


As you can see in the previous screenshot, the truncation for our myCustom feedback mode 
was successfully changed from the 80 inherited from the verbose mode to 60, based on 
our use of the /set truncation myCustom 60 JShell command. 
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Listing your assets 


There are a few JShell commands that are convenient for listing assets that you have 
created. Using the feedback demonstration from the previous section, we executed the 
/vars, /methods, and /1ist commands to provide a list of variables, methods, and all 
sources respectively: 


Command Prompt - jshell 


em.out.printin("Your result is " + (myVa 


We can also use the /1ist -all command and option combination to see what packages 
the JShell imported. As you can see in the following screenshot, JShell imported several 
packages that make our work within the shell more convenient, saving us time from having 
to import these standard packages in our methods: 


EA Command Prompt - jshell 


import 


v 


nun 


t 
t 
"E 
t 
t 
E 
E 
t 


em.out.printlr 
tem.out.println( 
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If you just want to list the startup imports, you can use the /list -start command and 
option combination. As you can see in the following screenshot, each start up import has an 


mow 


s" prefix and is numerically ordered: 


Gs Command Prompt - jshell 


Editing in the JShell 


JShell is not a full-featured text editor, but there are several things you can do within the 
shell. This section provides you with the editing techniques grouped into modifying text, 
basic navigation, historical navigation, and advanced editing commands. 


Modifying text 
The default text edit/entry mode is that the text you type will appear at the current cursor 
position. You have several options available to you when you want to delete text. Here is a 


complete list: 
PC keyboard Mac keyboard 
combination combination 
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Delete from the cursor location to the previous Ctrl + W Cmd + W 
white space 

Paste the most recently deleted text at the cursor | Ctrl + Y Cmd + Y 
location 


When the Ctrl + Y (or Cmd + Y on Mac) is used, you | Alt + Y Alt/Opt + Y 
will be able to use the Alt + Y keyboard 

combination to cycle through previously deleted 

text 


Basic navigation 


While navigational control inside the JShell is similar to most command-line editors, it is 
helpful to have a list of basic navigational controls: 


Down arrow Move down one line forward through history 


Enter (submit) the current line 


Jump back one word 


Historical navigation 


JShell remembers the snippets and commands that you enter. It maintains this history so 
that you can reuse snippets and commands you already entered. To cycle through snippets 
and commands, you can hold down the Ctrl key (cmd on Mac) and then use the up and 
down arrow keys until you see the snippet or command you want. 
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Advanced editing commands 


There are several more editing options to include search functionality, macros creation and 
use, and more. JShell's editor is based on JLine2, a Java library for parsing console input and 
editing. You can learn more about JLine2 at this URL: https: //github.com/jline/jline2/ 
wiki/JLine-2.x-Wiki. 


Working with scripts 


Up to this point, you have entered data directly into JShell from the keyboard. You also 
have the ability to work with JShell scripts which are a sequence of JShell commands and 
snippets. The format is the same as other scripting formats with one command per line. 


In this section, we will look at start up scripts, examine how to load scripts, how to save 
scripts, and then end with a look at advanced scripting with JShell. 


Start up scripts 


Each time the JShell is launched, the start up scripts are loaded. This also occurs each time 
the /reset, /reload, and /env commands are used. 


By default, the DEFAULT start up script is used by JShell. If you want to use a different 
start up script, you merely need to use the /set start <script> command. Here is an 
example--/set start MyStartupScript.jsh. Alternatively, you can use the jshell -- 
start MyStartupScript.jsh command at the Command Prompt to launch JShell and 
load the MyStartupScript.jsh JShell start up script. 


When you use the /set start <script> command with the -retain option, you are 
telling JShell to use the new start up script the next time you launch JShell. 
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Loading scripts 


Loading scripts in the JShell can be accomplished with one of the following methods: 


e You can use the /open command along with the name of the script as a 
parameter. For example, if our script name is MyScript, we would use /open 
MyScript. 

e A second option for loading scripts is to use the jshell MyScript.jsh atthe 
Command Prompt. This will launch JShell and load the MyScript . jsh JShell 
script. 


Saving scripts 


In addition to creating JShell scripts in external editors, we can create them within the JShell 
environment as well. When taking this approach, you will need to use the /save command 
to save your scripts. As you can see in the following screenshot, the /save command 
requires, at a minimum, a file name argument: 


ie Command Prompt - jshell 


There are three options available to you with the /save command: 


e The -a11 option can be used to save the source of all snippets to the specified file. 


e The -history option saves a sequential history of all commands and snippets 
you entered since JShell was launched. JShell's ability to perform this operation 
informs you that it maintains a history of everything you enter. 

e The -start option saves the current start up definitions to the specified file. 
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Advanced scripting with JShell 


What are the limits of JShell? There is so much you can do with this tool, and you are 
virtually only limited by your imagination and programming abilities. 


Let's look at an advanced code base that can be used to compile and run Java programs 
from a JShell script: 


import java.util.concurrent.* 
import java.util.concurrent.* 
import java.util.stream.* 
import java.util.* 


void print2Console(String thetext) 
{ 
System.out.printin(thetext) ; 
System.out.printin(""); 


void runSomeProcess (String... args) throws Exception 
{ 
String theProcess = 
Arrays.asList (args) .stream() .collect ( 


Collectors.joining(" ")); 
print2Console("You asked me to run: '"+theProcess+"'"); 
print2Console(""); 


ProcessBuilder compileBuilder = new 
ProcessBuilder (args) .inheritI0O(); 

Process compileProc = compileBuilder.start (); 

CompletableFuture<Process> compileTask = 
compileProc.onExit (); 

compileTask.get(); 


print2Console("JShell session launched.") 
print2Console("Preparing to compile Sample.java. . . ") 


// run the Java Compiler to complete Sample.java 
runSomeProcess("javac", "Sample.java") 
print2Console ("Compilation complete.") 
print2Console("Preparing to run Sample.class...") 


// run the Sample.class file 
runSomeProcess("java", "Sample") 


print2Console("Run Cycle compete.") 


// exit JShell 
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print2Console("JShell Termination in progress...) 
print2Console("Session ended.") 


/exit 


As you can see with this script, we created a runSomeProcess () method and can use it to 
explicitly compile and run external Java files. 


Summary 


In this chapter, we examined JShell, Java 9's new read-eval-print loop command-line tool. 
We started with introductory information regarding the tool and looked closely at the read- 
eval-print loop concept. We spent considerable time reviewing JShell commands and 
command-line options. Our coverage included practical guides to feedback modes, asset 
listing, and editing in the shell. We also gained experience working with scripts. 


In the next chapter, we will look at Java 9's new default garbage collector. Specifically, we 
will look at the default garbage collection, depreciated garbage collection combinations, and 
examine garbage collection logging. 
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In the previous chapter, we examined Java Shell (JShell), Java 9's new read-eval-print loop 
(REPL) command-line tool. We started with introductory information regarding the tool 
and looked closely at the read-eval-print loop concept. We spent considerable time 
reviewing JShell commands and command-line options. Our coverage included practical 
guides to feedback modes, asset listing, and editing in the shell. We also gained experience 
working with scripts. 


In this chapter, we will take an in-depth look at garbage collection and how it is handled in 
Java 9. We will start with an overview of garbage collection, and then look at specifics in the 
pre-Java 9 realm. Armed with that foundational information, we will look at specific 
garbage collection changes in the Java 9 platform. Lastly, we will look at some garbage 
collection issues that persist, even after Java 9. 


The following topics are covered in this chapter: 


e Overview of garbage collection 

e The pre-Java 9 garbage collection schema 

e Collecting garbage with the new Java platform 
e Persistent issues 
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Overview of garbage collection 


Garbage collection is the mechanism used in Java to deallocate unused memory. Essentially, 
when an object is created, memory space is allocated and dedicated to that object until it no 
longer has any references pointing to it. At that time, the system deallocates the memory. 
Java performs this garbage collection automatically for us, which can lead to a lack of 
attention to memory usage and poor programming practices in the area of memory 
management and system performance. 


Java's garbage collection is considered an automatic memory management schema because 
programmers do not have to designate objects as ready to be deallocated. The garbage 
collection runs on a low-priority thread and, as you will read later in this chapter, has 
variable execution cycles. 


In our overview of garbage collection, we will look at the following concepts: 


e Object life cycle 

e Garbage collection algorithms 

e Garbage collection options 

e Java methods relevant to garbage collection 


We will look at each of these concepts in the sections that follow. 


Object life cycle 


In order to fully understand Java's garbage collection, we need to look at the entire life cycle 
of an object. Because the core of garbage collection is automatic in Java, it is not uncommon 
to see the terms garbage collection and memory management as assumed components of the 
object life cycle. 


We will start our review of the object life cycle with object creation. 


Object creation 


Objects are declared and created. When we write an object declaration, or declare an object, 
we are declaring a name or identifier so that we can refer to an object. For example, the 
following line of code declares myObjectName as the name of an object of type 
CapuchinMonkey. At this point, no object was created and no memory allocated for it: 


CapuchinMonkey myObjectName; 


[ 156 ] 


www.EBooksWorld.ir 


Leveraging the New Default G1 Garbage Collector 


We use the new keyword to create an object. The following example illustrates how to 
invoke the new operation to create an object. This operation results in: 


myObjectName = new CapuchinMonkey (); 


Of course, we can combine the declaration and creation statements together by using 
CapuchinMonkey myObjectName = new CapuchinMonkey (); instead of 
CapuchinMonkey myObjectName; and myObjectName = new CapuchinMonkey ();. 
They were separated in the preceding example for illustrative purposes. 


When an object is created, a specific amount of memory is allocated for storing that object. 
The amount of memory allocated can differ based on architecture and JVM. 


Next look at the mid-life of an object. 


Object mid-life 

Objects are created and Java allocates system memory for storing that object. If the object is 
not used, the memory allocated to it is considered wasted. This is something we want to 
avoid. Even with small applications, this type of wasted memory can lead to poor 
performance and even out-of-memory issues. 


Our goal is to deallocate or release the memory, any previously allocated memory that we 
no longer need. Fortunately, with Java, there is a mechanism for handling this issue. It is 
called garbage collection. 


When an object, such as our myObjectName example, no longer has any references pointing 
to it, the system will reallocate the associated memory. 


Object destruction 


The idea of Java having a garbage collector running in the dark shadows of your code 
(usually a low-priority thread) and deallocating memory currently allocated to 
unreferenced objects, is appealing. So, how does this work? The garbage collection system 
monitors objects and, as feasible, counts the number of references to each object. 


When there are no references to an object, there is no way to get to it with the currently 
running code, so it makes perfect sense to deallocate the associated memory. 


[ 157 ] 


www.EBooksWorld.ir 


Leveraging the New Default G1 Garbage Collector 


improperly deallocated. These leaks are avoidable with Java's garbage 


The term memory leak refers to small memory chunks to be lost or 
a collection. 


Garbage collection algorithms 


There are several garbage collection algorithms, or types, for use by the Java virtual 
machine. In this section, we will cover the following garbage collection algorithms: 


e Mark and sweep 

e CMS garbage collection 

e Serial garbage collection 

e Parallel garbage collection 
e G1 garbage collection 


Mark and sweep 


Java's initial garbage collection algorithm, mark and sweep, used a simple two-step process: 


1. Java first step, mark, is to step through all objects that have accessible references, 
marking those objects as alive. 

2. The second step, sweep, involves scanning the sea for any object that is not 
marked. 


As you can readily determine, the mark and sweep algorithm seems effective, but probably 
not very efficient due to the two-step nature of this approach. This eventually lead to a Java 
garbage collection system with vastly improved efficiencies. 


Concurrent mark sweep (CMS) garbage collection 


The concurrent mark sweep (CMS) algorithm for garbage collection scans heap memory 
using multiple threads. Similar to the mark and sweep method, it marks objects for removal 
and then makes a sweep to actually remove those objects. This method of garbage collection 
is essentially an upgraded mark and sweep method. It was modified to take advantage of 
faster systems and had performance enhancements. 
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To manually invoke the concurrent mark sweep garbage collection algorithm for your 
application, use the following command-line option: 


-XX : +UseConcMarkSweepGC 


If you want to use the concurrent mark sweep garbage collection algorithm and dictate the 
number of threads to use, you can use the following command-line option. In the following 
example, we are telling the Java platform to use the concurrent mark sweep garbage 
collection algorithm with eight threads: 


-XX:ParallelCMSThreads=8 


Serial garbage collection 


Java's serial garbage collection works on a single thread. When executing, it freezes all other 
threads until garbage collection operations have concluded. Due to the thread-freezing 
nature of serial garbage collection, it is only feasible for very small programs. 


To manually invoke the serial garbage collection algorithm for your application, use the 
following command-line option: 


-XX:+UseSerialGC 


Parallel garbage collection 


Prior to Java 9, the parallel garbage collection algorithm was the default garbage collector. It 
uses multiple threads but freezes all non-garbage collection threads in the application until 
garbage collection functions have completed, just like the serial garbage collection 
algorithm. 


G1 garbage collection 


The G1 garbage collection algorithm was created for use with large memory heaps. This 
approach involves segmenting the memory heap into regions. Garbage collection, using the 
G1 algorithm, takes place in parallel with each heap region. 


Another part of the G1 algorithm is that when memory is deallocated, the heap space is 
compacted. Unfortunately, the compacting operation takes place using the Stop the World 
approach. 


The G1 garbage collection algorithm also prioritizes the regions based on those that have 
the most garbage to be collected. 
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The G1 name refers to Garbage First. 


To manually invoke the G1 garbage collection algorithm for your application, use the 
following command-line option: 


-XX : +UseG1GC 


Garbage collection options 
Here is a list of JVM sizing options: 


Sizing description JVM option flag 


Sets the initial heap size (young space plus tenured -XX:InitialHeapSize=3g 
space). 

Sets the maximum heap size (young space plus tenured -XX:MaxHeapSize=3g 
space). 

Sets the initial and maximum heap size (young space plus | -Xms2048m —Xmx3g 
tenured space). 


Sets the initial size of young space. -XX:NewSize=128m 
Sets the maximum size of young space. —-XX:MaxNewSize=128m 


Sets young space size. Uses ration of young verses -XX:NewRation=3 
tenured space. In the sample flag to the right, 3 means 

that young space will be three times smaller than tenured 

space. 


Sets the size of single survivor space as a portion of Eden | -XX:SurvivorRatio=15 
space size 


Sets the initial size of the permanent space. XX:PermSize=512m 
Sets the maximum size of the permanent space. -XX:MaxPermSize=512m 


Sets the size of the stack area dedicated to each thread in |-Xss512k 

bytes. 

Sets the size of the stack area dedicated to each thread in |-XX:ThreadStackSize=512 
Kbytes. 
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Sets the maximum size of off-heap memory available to -XX:MaxDirectMemorySize=3g 
the JVM. 


Here is a list of young garbage collection options: 


Young garbage collection tuning option 


Sets the initial value for the number of collections |-XX: Initial\TenuringThreshold=16 
before an object will be promoted from young to 

tenured space. This is referred to as the tenuring 

threshold. 


Sets the maximum value for tenuring threshold. -XX:Max\TenuringThreshold=30 


Sets the maximum object size allowed to be XX:Pretenure\SizeThreshold=3m 
allocated in young space. If an object is larger 

than the maximum size it will be allocated to 

tenured space and bypass young space. 


This can be used to promote all young objects -XX:+AlwaysTenure 
surviving the young collection to tenured space. 

With this tag, objects from young space never get | -XX:+NeverTenur 
promoted to tenured space as long as the survivor 

space has sufficient room for them. 

We can indicate that we want to use thread local |-XX:+UseTLAB 
allocation blocks in the young space. This is 

enabled by default. 


Toggle this to allow the JVM to adaptively resize |—-XX:+ResizeTLAB 
the TLAB (Thread Local Allocation Blocks) for 
threads. 


Sets the initial size of TLAB for a thread. 
Sets the minimum allowable size of TLAB. —-XX:MinTLABSize=128k 
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Here is a list of concurrent mark sweep (CMS) tuning options: 


Indicates that you want to | -XX:+UseCMSInitiating\OccupancyOnly 
solely use occupancy as a 

criterion for starting a 

CMS collection operation. 


Sets the percentage CMS | -XX:CMSInitiating\OccupancyFraction=70 
generation occupancy to 

start a CMS collection 

cycle. If you indicate a 

negative number, you are 

telling the JVM you want 

to use 

CMSTriggerRatio. 


Sets the percentage CMS : CMSBoot st rap\Occupancy=10 
generation occupancy that 

you want to initiate a 

CMS collection for 

bootstrapping collection 

statistics. 


This is the percentage of :CMSTriggerRatio=70 
MinHeapFreeRatio in 

CMS generation that is 

allocated prior to a CMS 

cycle starts. 


Sets the percentage of :CMSTriggerPermRatio=90 
MinHeapFreeRatioin 

the CMS permanent 

generation that is 

allocated before starting a 

CMS collection cycle. 


This is the wait duration :CMSWaitDuration=2000 
after a CMS collection is 

triggered. Use the 

parameter to specify how 

long the CMS is allowed 

to wait for young 

collection. 
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Enables parallel remark. 


Enables parallel remark of 
survivor space. 


You can use this to force 
young collection before 
the remark phase. 


Use this to prevent 
scheduling remark if 
Eden used is below the 
threshold value. 


Sets the Eden occupancy 
percentage that you want 
CMS to try and schedule a 
remark pause. 


This is where you want to 
start sampling Eden top at 
least before young 
generation occupancy 


reaches 1/4" (in our 
sample to the right) of the 
size at which you want to 
schedule remark. 


You can select 
variant=1 or 
variant=2 of 
verification following 
remark. 


Elects to use the parallel 
algorithm for young space 
collection. 


Enables the use of 
multiple threads for 
concurrent phases. 


Sets the number of 
parallel threads used for 
the concurrent phases. 


-XX:+CMSParall 


:+CMSParall 


1\RemarkEnabled 


1\SurvivorRemarkEnabled 


:+CMSScavengeBeforeRemark 


:+CMSScheduleRemark\EdenSizeThreshold 


:CMSScheduleRemark\! 


EdenPenetration=20 


:CMSScheduleRemark\SamplingRatio=4 


:CMSRemarkVerifyVariant=1 


:+UseParNewGC 


:+CMSConcurrentMTEnabled 


:ConcGCThreads=2 
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Sets the number of : ParallelGCThreads=2 
parallel threads you want 

used for stop-the-world 

phases. 


You can enable :+CMSIncrementalMode 
incremental CMS (iCMS) 
mode. 


If this is not enabled, CMS | -XX:+CMSClassUnloadingEnabled 
will not clean permanent 
space. 


This allows :+ExplicitGCInvokes\Concurrent 
System.gc() to trigger 

concurrent collection 

instead of a full garbage 

collection cycle. 


This allows ExplicitGCInvokes\ConcurrentAndUnloadsClasses 
System.gc() to trigger 

concurrent collection of 

permanent space. 


iCMS (incremental concurrent mark sweep) mode is intended for servers 
with a small number of CPUs. It should not be employed on modern 
hardware. 


Here are some miscellaneous garbage collection options: 


Miscellaneous garbage collection options 


This will cause the JVM to ignore any -XX:+DisableExplicitGC 
System.gc() method invocations by an 
application. 


This is the (soft reference) time to live in -XX:SoftRefLRU\PolicyMSPerMB=2000 
milliseconds per MB of free space in the heap. 


This is the use policy used to limit the time XX:+UseGCOverheadLimit 
spent in garbage collection before an 
OutOfMemory error is thrown. 
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This limits the proportion of time spent in -XX:GCTimeLimit=95 
garbage collection before an Out OfMemory 
error is thrown. This is used with 


GCHeapFreeLimit. 


This sets the minimum percentage of free space | -XX:GCHeapFreeLimit=5 
after a full garbage collection before an 

OutOfMemory error is thrown. This is used with 

GCTimeLimit. 


Finally, here are some G1 specific options. Note that, these are all supported starting with 
JVM 6u26: 


Size of the heap region. The default is 2,048 and the -XX:G1lHeapRegionSize=16m 
acceptable range is 1 MiB to 32 MiB. 

This is the confidence coefficient pause prediction -XX:G1ConfidencePercent=75 
heuristics. 


This determines the minimum reserve in the heap. -XX:G1lReservePercent=5 


This is the garbage collection time per MMU--time ~XX:MaxGCPauseMillis=100 

slice in milliseconds. 

This is the pause interval time slice per MMU in -XX:GCPauseIntervalMillis=200 
milliseconds. 


MiB stands for Mebibyte which is a multiple of bytes for digital 
information. 


Java methods relevant to garbage collection 


Let's look at two specific methods associated with garbage collection. 
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The System.gc() method 


Although garbage collection is automatic in Java, you can make explicit calls to the 
java.lang.System.gc() method to aid in the debugging process. This method does not 
take any parameters and does not return any value. It is an explicit call that runs Java's 
garbage collector. Here is a sample implementation: 


System.gc(); 
System.out.printin("Garbage collected and unused 
memory has been deallocated."); 


Let's look at a more in-depth example. In the following code, we start by creating an 
instance of the Runtime, using Runtime myRuntime = Runtime.getRuntime(); which 
returns a singleton. This gives us access to the JVM. After printing some header information 
and initial memory stats, we create an ArrayList witha size of 300000. Then, we create a 
loop that generates 100000 array list objects. Lastly, we provide output in three passes, 
asking the JVM to invoke the garbage collector with 1 second pauses in between. Here is the 
source code: 


package MyGarbageCollectionSuite; 


import java.util.ArrayList; 
import java.util.concurrent.TimeUnit; 


public class GCVerificationTest 
{ 
public static void main(String[] args) throws 
InterruptedException 
{ 
// Obtain a Runtime instance (to communicate 
with the JVM) 
Runtime myRuntime = Runtime.getRuntime(); 


// Set header information and output initial 
memory stats 
System.out.printin("Garbage Collection 
Verification Test"); 

System.out.printin(" 


")i 


System.out.printin("Initial JVM Memory: " + 
myRuntime.totalMemory() + 
"\tFree Memory: " + myRuntime.freeMemory()); 
// Use a bunch of memory 
ArrayList<Integer> AccountNumbers = new 


ArrayList<>(300000); 
for (int i = 0; i < 100000; i++) 
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{ 
AccountNumbers = new ArrayList<>(3000); 
AccountNumbers null; 


} 


// Provide update with with three passes 
for (int i = 0; i < 3; i++) 
{ 


System.out.printin(" 


System.out.printin("Fr Memory befor 
collection number " + 
(i+1) + ": " + myRuntime.freeMemory ()); 
System.gc(); 
System.out.printin("Free Memory after 


collection number " + 
(i+1) + ": " + myRuntime.freeMemory ()); 
TimeUnit.SECONDS.sleep(1); // delay thread 
1 second 


} 


As you can see from the following output, the garbage collector did not reallocate all of the 
‘garbage’ during the first or even the second pass: 


Garbage Collection Verification Test 


Free Memory before collection number 1: 768241776 
Memory after collection number 1: 888052656 


Memory before collection number 2: 888052656 
Memory after collection number 2: 887536992 


Free Memory before collection number 3: 887536992 
Free Memory after collection number 3: 888061280 


There is an alternative to using the System. gc () method to invoke the garbage collector. In 
our example, we could have used myRuntime.gc (), our earlier singleton example. 
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The finalize() method 


You can think of Java's garbage collector as a death dealer. When it removes something 
from memory, it is gone. This so-called death dealer is not without compassion as it 
provides each method with their final last words. The objects give their last words through a 
finalize() method. If an object has a finalize () method, the garbage collector invokes 
it before the object is removed and the associated memory deallocated. The method takes no 
parameters and has a return type of void. 


The finalize () method is only called once and there can be variability when it is run. 
Certainly, the method is invoked before it is removed, but when the garbage collector runs 
is dependent on the system. If, as an example, you have a relatively small app that is 
running a memory-rich system, the garbage collector might not run at all. So, why include a 
finalize() method at all? It is considered poor programming practice to override the 
finalize() method. That being said, you can use the method if needed. In fact, you can 
add code there to add a reference to your object to ensure it is not removed by the garbage 
collector. Again, this is not advisable. 


Because all objects in Java, even the ones you create yourself are child classes of 
java.lang.Object, every object in Java has a finalize() method. 


The garbage collector, as sophisticated as it is, might not close databases, files, or network 
connections the way you want it done. If your application requires specific considerations 
when its objects are collected, you can override the object's finalize () method. 


Here is an example implementation that demonstrates a use case for when you might want 
to override an object's finalize () method: 


public class Animal 

{ 
private static String animalName; 
private static String animalBreed; 
private static int objectTally = 0; 


// constructor 
public Animal (String name, String type) 
{ 

animalName = name; 

animalBreed = type; 


// increment count of object 
t++objectTally; 
} 


protected void finalize () 
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// decrement object count each time this method 
// is called by the garbage collector 
--objectTally; 


//Provide output to user 
System.out.printin(animalName + " has been 
removed from memory."); 


// condition for 1 animal (use singular form) 

if (objectTally == 1) 

{ 
System.out.printin("You have " + objectTally + " 
animal remaining."); 


} 


// condition for 0 or greater than 1 
animals (use plural form) 
else 


{ 
System.out.printin("You have " + objectTally + " 
animals remaining."); 


} 


As you can see in the preceding code, the object Tally count is incremented each time an 
object of type Animal is created and decremented when one is removed by the garbage 
collector. 


Overriding an object's finalize () method is usually discouraged. The 
finalize() method should normally be declared as protected. 


Pre-Java 9 garbage collection 


Java's garbage collection is not new to Java 9, it has existed since the initial release of Java. 
Java has long had a sophisticated garbage collection system that is automatic and runs in 
the background. By running in the background, we are referring to garbage collection 
processes running during idle times. 
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Idle times refer to the time in between input/output such as between 
keyboard input, mouse clicks, and output generation. 


This automatic garbage collection has been one of the key factors in developers selecting 
Java for their programming solutions. Other programming languages such as C# and 
Objective-C have implemented garbage collection following the success of the Java 
platform. 


Let's next take a look at the following listed concepts before we look at the changes to 
garbage collection in the Java 9 platform: 

e Visualizing garbage collection 

e Garbage collection upgrades in Java 8 

e Case study - Games written with Java 


Visualizing garbage collection 


It can be helpful to visualize how garbage collection works and, perhaps more importantly, 
the need for it. Consider the following code snippet that progressively creates the string 
Garbage: 


001 String var = new String("G"); 


002 var += "a"; 

003 var += "r"; 

004 var += "b"; 

005 var += "a"; 

006 var += "g"; 

007 var += "e"; 

008 System.out.println("Your completed String 
isi Mẹ vyvar ae ce 


Clearly, the preceding code generates the output provided as follows: 


Your completed String is Garbage. 


What might not be clear is that the sample code results in five unreferenced string objects. 
This is due, in part, because strings are immutable. As you can see in the following 
illustration, with each successive line of code, the referenced object is updated and an 
additional object becomes unreferenced: 
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Line of Code 001 


String var = 
new 
String(“G”); 


Referenced var > var > 
memory “Ga” r “Garbag” “Garbage” 


Unreferenced 
memory 


The preceding unreferenced objects listed certainly will not break the memory bank, but it 
is indicative of how quickly a large number of unreferenced objects can accumulate. 


Garbage collection upgrades in Java 8 


As of Java 8, the default garbage collection algorithm was the parallel garbage collector. 
Java 8 was released with some improvements to the G1 garbage collection system. One of 
these improvements was the ability to use the following command-line option to optimize 
the heap memory by removing duplicative string values: 


-XX:+UseStringDeduplication 


The G1 garbage collector can view the character arrays when it sees a string. It then takes 
the value and stores it with a new, weak reference to the character array. If the G1 garbage 
collector finds a string with the same hash code, it will compare the two strings with a 
character-by-character review. If a match is found, both strings end up pointing to the same 
character array. Specifically, the first string will point to the character array of the second 
string. 


This method can require substantial processing overhead and should only be used if 
deemed beneficial or absolutely necessary. 
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Case study - Games written with Java 


Multiplayer games require extensive management techniques, both for server and client 
systems. The JVM runs the garbage collection thread in a low-priority thread and 
periodically runs. Server administrators previously used an incremental garbage collection 
schema using the now depreciated -Xincgc command-line option to avoid server stalls 
that occur when the server is overloaded. The goal is to have garbage collection run more 
frequently and with much shorter execution cycles each time. 


When considering memory usage and garbage collection, it is important to 
use as little memory on the target system as possible and to limit pauses 
for garbage collection to the extent feasible. These tips are especially 
important for games, simulations, and other applications that require real- 
time performance. 


The JVM manages the heap where Java memory is stored. The JVM starts with a small heap 
by default and grows as additional objects are created. The heap has two partitions--young 
and tenured. When objects are initially created, they are created in the young partition. 
Persistent objects are moved to the tenure partition. The creation of objects is usually very 
quick with not much more than pointer incrementation. Processing in the young partition is 
much faster than that of the tenured partition. This is important because it applies to the 
overall app, or in our case, a game's efficiency. 


It becomes important for us to monitor our game's memory usage and when garbage 
collection occurs. To monitor garbage collection, we can add the verbose flag (- 
verbose:gc) when we launch our game such as with the following example: 


java -verbose:gc MyJavaGameClass 


The JVM will then provide a line of formatted output for each garbage collection. Here is 
the format of the verbose GC output: 


[<TYPE> <MEMORY USED BEFORE> -> MEMORY USED AFTER 
(TOTAL HEAP SIZE), <TIME>] 


Let's look at two examples. In this first example, we see GC for type which refers to the 
young partition we previously discussed: 


[GC 31924K -> 29732K(42234K), 0.0019319 secs] 
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In this second example, Full GC indicates that the garbage collection action was taken on 
the tenured partition of the memory heap: 


[Full GC 29732K -> 10911K(42234K), 0.0319319 secs] 


You can obtain more detailed information from the garbage collector using the - 
XX:+PrintGCDetails option as shown here: 


java -verbose:gc -XX:+PrintGCDetails MyJavaGameClass 


Collecting garbage with the new Java 
platform 


Java came out of the gate with automatic garbage collection, making it a development 
platform of choice for many programmers. It was commonplace to want to avoid manual 
memory management in other programming languages. We have looked in-depth at the 
garbage collection system to include the various approaches, or algorithms, used by the 
JVM. Java 9 includes some relevant changes to the garbage collection system and was the 
focus of three Java Enhancement Program (JEP) issues. Those issues are listed here: 


e Default garbage collection (JEP 248) 
e Depreciated garbage collection combinations (JEP 214) 
e Unified garbage collection logging (JEP 271) 


We will review each one of these garbage collection concepts and their corresponding Java 
Enhancement Plan (JEP) issue in the following sections. 


Default garbage collection 


We previously detailed the following garbage collection approaches used by the JVM prior 
to Java 9. These are still plausible garbage collection algorithms: 


e CMS garbage collection 

e Serial garbage collection 

e Parallel garbage collection 
e G1 garbage collection 
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Let's briefly recap each of these approaches: 


e CMS garbage collection: The CMS garbage collection algorithm scans heap 
memory using multiple threads. Using this approach, the JVM marks objects for 
removal and then makes a sweep to actually remove them. 

e Serial garbage collection: This approach uses a thread-freezing schema on a 
single thread. When the garbage collection is in progress, it freezes all other 
threads until garbage collection operations have concluded. Due to the thread- 
freezing nature of serial garbage collection, it is only feasible for very small 
programs. 

e Parallel garbage collection: This approach uses multiple threads but freezes all 
non-garbage collection threads in the application until garbage collection 
functions have completed, just like the serial garbage collection algorithm. 

e G1 garbage collection: This is the garbage collection algorithm with the 
following characteristics: 

e Is used with large memory heaps 

e Involves segmenting the memory heap into regions 

e Takes place in parallel with each heap region 

e Compacts the heap space when memory is deallocated 

e Compacting operations take place using the Stop the World 
approach 

e Prioritizes the regions based on those that have the most garbage to 
be collected 


Prior to Java 9, the parallel garbage collection algorithm was the default garbage collector. 
In Java 9, the G1 garbage collector is the new default implementation of Java's memory 
management system. This is true for both 32 and 64-bit server configurations. 


Oracle assessed that the G1 garbage collector, mostly due to its low-pause nature, was a 
better performing garbage collection method than the parallel approach. This change was 
predicated on the following concepts: 


e It is important to limit latency 
e Maximizing throughput is less important than limiting latency 
e The G1 garbage collection algorithm is stable 
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There are two assumptions involved with making the G1 garbage collection method the 
default method over the parallel approach: 


e Making G1 the default garbage collection method will significantly increase its 
use. This increased usage might unveil performance or stability issues not 
realized before Java 9. 

e The G1 approach is more processor-intensive than the parallel approach. In some 
use cases, this could be somewhat problematic. 


On the surface this change might seem like a great step for Java 9 and that very well might 
be the case. Caution, however, should be used when blindly accepting this new default 
collection method. It is recommended that systems be tested if switching to G1 to ensure 
your applications do not suffer from performance degradation or have unexpected issues 
that are caused by the use of G1. As previously suggested, G1 has not benefited from the 
widespread testing that the parallel method has. 


This last point about the lack of widespread testing is significant. Making G1 the default 
automatic memory management (garbage collection) system with Java 9 is tantamount to 
turning developers into unsuspecting testers. While no major problems are expected, 
knowing that there is potential for performance and stability issues when using G1 with 
Java 9 will place greater emphasis on testing your Java 9 applications. 


Depreciated garbage collection combinations 


Oracle has been great about depreciating features, APIs, and libraries before removing them 
from a new release to the Java platform. With this schema in place, language components 
that were depreciated in Java 8 are subject for removal in Java 9. There are a few garbage 
collection combinations that were deemed to be rarely used and depreciated in Java 8. 
Those combinations, listed here, have been removed in Java 9: 


e DefNew + CMS 
e ParNew + SerialOld 
e Incremental CMS 


These combinations, in addition to having been rarely used, introduced an unneeded level 
of complexity to the garbage collection system. This resulted in an extra drain on system 
resources without providing a commensurate benefit to the user or developer. 
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The following listed garbage collection configurations were affected by the aforementioned 
depreciation in the Java 8 platform: 


Garbage collection configuration | Flag(s) 


DefNew + CMS XX:+UseParNewGC 
-XX:UseConcMarkSweepGC 
ParNew + SerialOld XX:+UseParNewGC 


ParNew + iCMS CMS IncrementalMode 
:+UseConcMarkSweepGC 

Defnew + ICMS :+CMSIncrementalMode 
:+UseConcMarkSweepGC 
:-UseParNewGC 


The Java Enhancement Program 214 (JEP 214) removed garbage collection combinations 
depreciated in JDK 8. Those combinations are listed above along with the flags that control 
those combinations. In addition, the flags to enable CMS foreground collections were 
removed and are not present in JDK 9. Those flags are listed as follows: 


CMS foreground -XX:+UseCMSCompactAtFullCollection 


CMS foreground -XX+CMSFullGCsBeforeCompaction 
CMS foreground -XX+UseCMSCollectionPassing 


The only assessed downside to the removal of the depreciated garbage collection 
combinations is that applications that use JVM start up files with any of the flags listed in 
this section, will need to have their JVM start up files modified to remove or replace the old 
flags. 


Unified garbage collection logging 


The Java Enhancement Program #271 (JEP-271) titled, Unified GC Logging, is intended to re- 
implement garbage collection logging using the unified JVM logging framework that was 
previously introduced with JEP-158. So, let's first review the Unified JVM Logging 
(JEP-158). 
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Unified JVM logging (JEP-158) 


Creating a unified logging schema for the JVM was the central goal of JEP-158. Here is a 
high-level list of the goals of the JEP: 


e Create a JVM-wide set of command-line options for all logging operations 
e Use categorized tags for logging 


e Provide six levels of logging: 
e Error 


e Warning 

e Information 
e Debug 

e Trace 

e Develop 


This is not an exhaustive list of goals. We will discuss JEP-158 in greater 
ac detailin chapter 14, Command Line Flags. 


The changes to the JVM, in the context of logging, can be categorized into: 


e Tags 

e Levels 

e Decorations 

e Output 

e Command-line options 


Let's briefly look at these categories. 


Tags 


Logging tags are identified in the JVM and can be changed in source code if needed. The 
tags should be self-identifying, such as gc for garbage collection. 
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Levels 


Each log message has an associated level. As previously listed, the levels are error, warning, 
information, debug, trace, and develop. The following chart shows how the levels have an 
increasing level of verbosity in respect to how much information is logged: 


Level of Verbosity 


aati | 


error warning info debug trace 


Logging Level 


Decorations 


In the context of Java 9's logging framework, decorations is metadata about the log 
message. Here is the alphabetic list of decorations that are available: 


level 

pid 

tags 

tid 

time 
timemillis 
timenanos 
uptime 
uptimemillis 
uptimenanos 


For an explanation of these decorations, please refer to Chapter 14, Command Line Flags. 
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Output 
The Java 9 logging framework supports three types of output: 


e stderr: Provides output to stderr 
e stdout: Provides output to stdout 
e text file: Writes the output to text files 


Command-line options 


A new command-line option was added to the logging framework to provide overall 
control of the JVM's logging operations. The -Xlog command-line option has an extensive 
array of parameters and possibilities. Here is one example: 


-Xlog:gctrt*=debug 
In this example, we are telling the JVM to take the following actions: 


e Log all messages tagged with, at a minimum, the gc and rt tags 
e Use the debug level 
e Provide output to stdout 


Unified GC logging (JEP-271) 


Now that we have a general understanding of the changes to Java 9's logging framework, 
let's look at what changes JEP-271 introduced. In this section we will look at the following 
areas: 


e Garbage collection logging options 
e The gc tag 

e Macros 

e Additional considerations 
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Garbage collection logging options 


Here is a list of garbage collection logging options and flags we had available to us before 
the introduction of Java 9's logging framework: 


JVM option flag(s) 


verbose:gc or ~XX:+PrintGC 
tPrintGCDetails 


-XX: 4 
You can print timestamps for each -XX:+PrintGCTimeStamps 
garbage collection event. The seconds are 
sequential and begin from the JVM start 
time. 


You can print date stamps for each -XX:+PrintGCDateStamps 
garbage collection event. Sample 
format: 
2017-07-26T03:19:00.319+400: [GC 
] 


You can use this flag to print timestamps |-XX:+PrintGC\TaskTimeStamps 
for individual garbage collection work 
thread tasks. 


Using this you can redirect garbage 
collection output to a file instead of the 
console. 


You can print detailed information -XX:+Print\TenuringDistribution 
regarding young space following each 
collection cycle. 


You can use this flag to print TLAB :+PrintTLAB 
allocation statistics. 


Using this flag, you can print the times :+PrintReferenceGC 
for reference processing (that is, weak, 

soft, and so on) during stop-the-world 

pauses. 


This reports if the garbage collection is -XX:+PrintdUNIGCStalls 
waiting for native code to unpin objects 
in memory. 
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This will print a pause summary after tPrintGC\ApplicationStoppedTime 
each stop-the-world pause. 


This flag will print time for each tPrintGC\ApplicationConcurrentTime 
concurrent phase of garbage collection. 


Using this flag will print a class tPrint\ClassHistogramAfterFull 
histogram after a full garbage collection. 


Using this flag will print a class tPrint\ClassHistogramBeforeFul 
histogram before a full garbage collection. 


This creates a heap dump file after full -XX:+HeapDump\AfterFullGc 
garbage collection. 


This creates a heap dump file before full |-XX:+HeapDump\BeforeFullGc 
garbage collection. 


This creates a heap dump file in an out- -XX:+HeapDump\OnOutOfMemoryError 
of-memory condition. 


You use this flag to specify the path -XX:HeapDumpPath=<path> 
where you want your heap dumps saved 
on your system. 


You can use this to print CMS statistics, | |-XX:PrintCMSStatistics=2 
if n >= 1. Applies specifically to CMS 
only. 


This will print CMS initialization details. |-XX:+Print\CMSInitiationStatistics 
Applies specifically to CMS only. 


You can use this flag to print additional |-XX:PrintFLSStatistics=2 
information concerning free lists. Applies 
specifically to CMS only. 


You can use this flag to print additional |-XX:PrintFLSCensus=2 
information concerning free lists. Applies 
specifically to CMS only. 


You can use this flag to print detailed -XX:+PrintPromotionFailure 
diagnostic information following a 

promotion (young to tenure) failure. 

Applies specifically to CMS only. 
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This flag allows you to dump useful -XX : +CMSDumpAt \PromotionFailure 
information regarding the state of the 

CMS old generation when a promotion 

(young to tenure) failure occurs. Applies 

specifically to CMS only. 


When the - -XX:+CMSPrint\ChunksInDump 
: +CMSDumpAt\PromotionFailure 

flag is used, you can use - 

:+CMSPrint \ChunksInDump to 

include additional details regarding free 

chunks. Applies specifically to CMS only. 


When using the - -XX:+CMSPrint\ObjectsInDump 
XX:+CMSPrint\ChunksInDump flag, 

you can include additional information 

about the allocated objects using the - 

XX:+CMSPrint\ObjectsInDump flag. 

Applies specifically to CMS only. 


The gc tag 


We can use the gc tag with the -X1log option to inform the JVM to only log gc tagged items 
at the info level. As you will recall, this is similar to using -XX :+PrintGc. With both 
options, the JVM will log one line for each garbage collection operation. 


It is important to note that the gc tag was not intended to be used on its own; rather, it is 
recommended that it be used in conjunction with other tags. 


Macros 


We can create macros to add logic to our garbage collection logging. Here is the general 
syntax for the log macro: 


log_<level>(Tagi[,...]) (fmtstr, ...) 
Here is an example of a log macro: 


log_debug(gc, classloading) ("Number of objects 
loaded: d.", object_count) 
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The following example skeleton log macro shows how you can use the new Java 9 logging 
framework to create scripts for greater fidelity in logging: 


LogHandle(gc, rt, classunloading) log; 
if (log.is_error()) 
{ 
// do something specific regarding the 'error' level 


} 


if (log.is_warning() ) 

{ 
// do something specific regarding the 'warning' 
level 


} 


if (log.is_info()) 
{ 
// do something specific regarding the 'info' level 


} 


if (log.is_debug() ) 
{ 
// do something specific regarding the 'debug' level 


} 


if (log.is_trace() ) 
{ 
// do something specific regarding the 'trace' level 


} 


Additional considerations 


Here are some additional items to be considered in regards to garbage collection logging: 


e Using the new -Xlog:gc should produce similar results to the - 
XX:+PrintGCDetails command-line option and flag pairing 

e The new trace level provides the level of detail previously provided with the 
verbose flag 
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Persistent issues 


Even with the advent of Java 9, there were downsides to Java's garbage collection system. 
Because it is an automatic process, we do not have complete control of when the collector 
runs. We, as developers, are not in control of garbage collection, the JVM is. The JVM makes 
the decision when to run garbage collection. As you have seen earlier in this chapter, we can 
ask the JVM to run garbage collection using the System. gc () method. Despite our use of 
this method, we are guaranteed that our request will be honored or that it will be complied 
with in a timely manner. 


Earlier in this chapter, we reviewed several approaches and algorithms for garbage 
collection. We discussed how we, as developers, can take control of the process. That 
assumes that we have the ability to take control of garbage collection. Even when we 
specify a specific garbage collection technique, for example using - 

XX: +UseConcMarkSweepGc for CMS garbage collection, we are not guaranteed that the 
JVM will use that implementation. So, we can do our best to control how the garbage 
collector works, but should remember that the JVM has the ultimate authority regarding 
how, when, and if garbage collection occurs. 


Our lack of complete control over garbage collection underscores the importance of writing 
efficient code with memory management in mind. In the next sections, we will examine 
how to write code to explicitly make objects eligible for garbage collection by the JVM. 


Making objects eligible for garbage collection 


An easy method for making objects available for garbage collection is to assign nu11 to the 
reference variable that refers to the object. Let's review this example: 


package MyGarbageCollectionSuite; 


public class GarbageCollectionExperimentOne 
{ 
public static void main(String[] args) 


{ 


// Declare and create new object. 
String junk = new String("Pile of Junk"); 


// Output to demonstrate that the object 

has an active reference 

// and is not eligible for garbage collection. 
System.out.printin (junk); 
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// Set the reference variable to null. 
junk = null; 


// The String object junk is now eligible 
for garbage collection. 


} 


As indicated in the in-code comments, once the string object reference variable is set to null, 
in this case using the junk = null; statement, the object becomes available for garbage 
collection. 


In our next example, we will abandon an object by setting its reference variable to point to a 
different object. As you can see in the following code, that results in the first object being 
available for garbage collection: 


package MyGarbageCollectionSuite; 


public class GarbageCollectionExperimentTwo 
{ 
public static void main(String[] args) 
{ 
// Declare and create the first object. 
String junki = new String("The first pile of 
Junk"); 


// Declare and create the second object. 
String junk2 = new String("The second pile of 
Junk"); 


// Output to demonstrate that both objects have 
active references 

// and are not eligible for garbage collection. 
System.out.printin(junk1); 
System.out.printin(junk2); 


// Set the first object's reference to th 
second object. 
junki = junk2; 


// The String "The first pile of Junk" is now 
eligible for garbage collection. 


[ 185 ] 


www.EBooksWorld.ir 


Leveraging the New Default G1 Garbage Collector 


} 


Let's review one final method of making objects available for garbage collection. In this 
example, we have a single instance variable (objectNbr) that is a reference variable to an 
Experiment Three class. The class does not do 
anything interesting other than create additional reference variables to instances of the 


instance of the GarbageCollectionl 


GarbageCollection! 


package MyGarbageCollectionSuite; 


{ 
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ExperimentThree Class. In our example, we set the objectNbr2, 
objectNbr3, objectNbr4, and objectNbr5 references to null. Although these objects 
have instance variables and can refer to each other, their accessibility outside of the class 
has been terminated by setting their references to nul1. This makes them ( objectNbr2, 
objectNbr3, objectNbr4, and objectNbr5 ) eligible for garbage collection: 


objectNbr; 


tNbr3 


tNbr4 


tNbr5 


tNbr2 
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objectNbr3 = null; 
objectNbr4 = null; 
objectNbr5 = null; 


Summary 


In this chapter we took an in-depth review of garbage collection as a critical pre-Java 9 
platform component. Our review included object life cycle, garbage collection algorithms, 
garbage collection options, and methods related to garbage collection. We looked at 
upgrades to garbage collection in Java 8 and looked at a case study to help our 
understanding of modern garbage collection. We then turned our focus to the changes to 
garbage collection with the new Java 9 platform. Our exploration of garbage collection in 
Java 9 included looks at default garbage collection, depreciated garbage collection 
combinations, and unified garbage collection logging. We concluded our exploration of 
garbage collection by looking at a few garbage collection issues that persist, even after Java 
9. 


In the next chapter we will look at how to write performance tests using the Java 
Microbenchmark Harness (JMH), a Java harness library for writing benchmarks for the 


JVM. 
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In the previous chapter, we took an in-depth review of garbage collection to include an 
object life cycle, garbage collection algorithms, garbage collection options, and methods 
related to garbage collection. We took a brief look at upgrades to garbage collection in Java 
8 and focused on changes with the new Java 9 platform. Our exploration of garbage 
collection in Java 9 included looks at default garbage collection, depreciated garbage 
collection combinations, unified garbage collection logging, and garbage collection issues 
that persist, even after Java 9. 


In this chapter, we will look at how to write performance tests using the Java 
Microbenchmark Harness (JMH), a Java harness library for writing benchmarks for the 
Java Virtual Machine (JVM). We will use Maven along with JMH to help illustrate the 
power of microbenchmarking with the new Java 9 platform. 


Specifically, we will cover the following topics: 


e Microbenchmarking overview 

e Microbenchmarking with Maven 

e Benchmarking options 

e Techniques for avoiding microbenchmarking pitfalls 
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Microbenchmarking overview 


Microbenchmarking is used to test the performance of a system. This differs from 
macrobenchmarking which runs tests on different platforms for efficiency comparison and 
subsequent analysis. With microbenchmarking, we typically target a specific slice of code 
on one system such as a method or loop. The primary purpose of microbenchmarking is to 
identify optimization opportunities in our code. 


There are multiple approaches to benchmarking and we will focus on using the JMH tool. 
So, why benchmark at all? Developers do not always concern themselves with performance 
issues unless performance is a stated requirement. This can lead to post-deployment 
surprises that could have been avoided if microbenchmarking was conducted as part of the 
development process. 


Microbenchmarking takes place across several phases of a process. As shown in the 
following diagram, the process involves design, implementation, execution, analysis, and 
enhancement: 


In the Design phase, we determine our goals and design our microbenchmark accordingly. 
In the Implement phase, we are writing the microbenchmark and then, in the Execution 
phase, we actually run the test. With microbenchmarking results in hand, we interpret and 
analyze the results in the Analysis phase. This leads to code improvements in the 
Enhancement phase. Once our code has been updated, we redesign the 
microbenchmarking test, adjust the implementation, or go straight to the Execution phase. 
This is a cyclical process that continues until we have achieved the performance 
optimization we identified in our goals. 
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Approach to using JMH 


Oracle's documentation indicates that the most ideal JMH use case is to use a Maven project 
that is dependent on the application's JAR files. They further recommend that 
microbenchmarking take place via the command-line and not from within an Integrated 
Development Environment (IDE), as that could impact the results. 


comprehension tool that we can use to manage our application project 


Maven, also referred to as Apache Maven, is a project management and 
ap build, reporting, and documentation. 


To use JMH, we will use bytecode processors (annotations) to generate the benchmark code. 
We use Maven archetypes to enable JMH. 


In order to test the JMH, we require an IDE with support for Maven and Java 9. If you do 
not yet have Java 9 or an IDE with Java 9 support, you can follow the steps in the next 
section. 


Installing Java 9 and Eclipse with Java 9 support 


You can download and install Java 9 from the JDK 9 early access builds page--http: //jdk. 
java.net/9/. 


Once you have Java 9 installed, download the latest version of Eclipse. At the time of 
writing this book, that was Oxygen. Here is the relevant link--https: //www.eclipse.org/ 
downloads/. 
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The next step is to enable Java 9 support in your IDE. Launch Eclipse Oxygen and select 
Help | Eclipse Marketplace... , as shown in the following screenshot: 


© eclipse-workspace - Eclipse 


File Edit Navigate Search Project Run Window Help 


Welcome 
Help Contents 


Search o the Eclipse IDE for Java Developers 
Show Contextual Help Workbench 
Show Active Keybindings... Ctrl+Shift+L 
Tips and Tricks... 


Report Bug or Enhancement... 


Cheat Sheets... n settings Overview 


Eclipse User Storage Open the Eclipse Marketplace wizard pd Get an overview of the features 


Perform Setup Tasks... 


Check for Updates 


Install New Software... lication 
the famous Hello 


Tutorials 
Go through tutorials 


S About Eclipse 


a Samples 
(+) Create a new Java project Try out the samples 
Create a new Java Eclipse project 


What's New 
> Checkout projects from Git Find out what is new 
Checkout Eclipse projects hosted in a Git repository 


4 Import existing projects 
Import existing Eclipse projects from the filesystem 
or archive 


Launch the Eclipse Marketplace 
Enhance your IDE with additional plugins and install 
your Marketplace favorites 


Always show Welcome at startup Y 
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With the Eclipse Marketplace dialog window present search for Java 9 support using 
the search box. As you can see in the following screenshot, you will be presented with an 
Install button: 


$ Eclipse Marketplace 


Eclipse Marketplace 


Select solutions to install. Press Install Now to proceed with installation. 
Press the "more info" link to learn more about a solution. 


Search Recent Popular Favorites Installed Q Eclipse Newsletter (July) 


Find: | 9 support Q | |All Markets v| All Categories 


Java 9 Support (BETA) for Oxygen 4.7 


Java™ 9 support has not yet landed in our standard download packages. But 
you can add an early access preview to your existing Eclipse Oxygen (4.7) 
install. The... more info 


by The Eclipse Foundation, EPL 
Java 9 Java 9 Support 


> Installs: 4.61K (766 last month) 


Marketplaces 


Install Now > Cancel 


During the installation process, you will be required to accept the license agreement and, 
upon completion, you will be required to restart Eclipse. 
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Hands-on experiment 


Now that we have Eclipse updated to support Java 9, you can run a quick test to determine 
if JMH is working on your development computer. Start by creating a new Maven project as 
illustrated in the following screenshot: 


S New Maven Project 


New Maven project 
Specify Archetype parameters 


Group Id; | com.packt.benchmark.test 


Artifact Id: 


Version: 0,0.1-SNAPSHOT 


Package: | com.packt.benchmark.test.com.packt.benchmark.test 


Properties available from archetype: 


| Name Value 


b Advanced 


FSN 


Next, we need to add a dependency. We can do this by editing the pom. xm1 file directly 
with the following code: 


<dependency> 
<groupId>org.openjdk.jmh</groupId> 
<artifactId>jmh-core</artifactId> 
<version>0.1</version> 
</dependency> 
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Alternatively, we can use the dependencies tab to enter the data in a dialog window, as 
shown in the following screenshot. Using this form updates the pom. xm1 file with the 
preceding code: 


& Select Dependency 


Group Id: *| org.openjdk.jmh 


Artifact Id: *| jmh-core 


Version: 0.1 


Enter groupld, artifactld or shal prefix or pattern (*): 


ndex downloads are disa search results ma incomplete. 
Index download disabled, h Its may be i pl 
Search Results: 
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Next, we need to write a class that contains a JMH method. This is just as an initial test to 
confirm our recently updated development environment. Here is sample code you can use 
for your test: 


package com.packt.benchmark.test.com.packt.benchmark.test; 
import org.open.jdk.jmh.Main; 


public class Test 


{ 


public static void main(String[] args) 
{ 
Main.main (args); 
} 
} 


We can now compile and run our very simple test program. The results are provided in the 
Console tab, or the actual console if you are using the command-line. Here is what you will 
see: 


<terminated> Test [Java Application] C:\Program Files\Java\jre1.8.0_131\bin\javaw.exe (Jul 30, 2017, 8:04:30 PM) 


No matching benchmarks. Miss-spelled regexp? Use -v for verbose output. 


You can see that the program worked sufficiently to let us know that JMH is working. Of 
course, there was, as the output indicates, no benchmarks set up. We will take care of that in 
the next section. 


Microbenchmarking with Maven 


One approach to getting started with JMH is to use the JMH Maven archetype. The first step 
is to create a new JMH project. At our system's command prompt, we will enter the mvn 
command followed by a long set of parameters to create a new Java project and the 
necessary Maven pom. xm1 file: 


mvn archetype:generate -DinteractiveMode=false - 
DarchetypeGroupId=org.openjdk.jmh -—DarchetypeArtifactId=jmh -java- 
benchmark-archetype —DgroupId=com.packt —DartifactId=chapter8—benchmark - 
Dversion=1.0 


[ 195 ] 


www.EBooksWorld.ir 


Microbenchmarking Applications with JMH 


Once you enter the mvn command and the preceding detailed parameters, you will see the 
results reported to you via the Terminal. Depending on your level of use, you might see a 
large number of downloads from https: //repo.maven.apache.org/maven2/org/apache/ 
mave/plugins and other similar repository sites. 


You will also see an information section that informs you about the project build process: 


(default-cli) > generate-sources @ 


(default-cli) < generate-sources @ 


(default-cli) @ 


There will likely be additional plugin and other resources downloaded from the nttps:// 
repo.maven.apache.org repositories. Then, you will see an informational feedback 
component that lets you know the project is being generated in batch mode: 


va-benchmark-archet 21.19] found in catalog remote 


Finally, you will be presented with a set of parameters and a note that your project build 
was successful. As you can see with the following example, the process took less than 21 
seconds to complete: 


nchmark-arche 
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A folder will be created based on the parameter we included in the -DartifactId option. 
In our example, we used —Dartifact Id=chapter8-benchmark, and Maven created a 
chapter8—benchmark project folder: 


Command Prompt 


ime in drive C is OS 
Volume Serial Number is 608F-FF3F 


C: \chapter8s-benchmark> 


You will see that Maven created the pom. xm1 file as well as a source (src) folder. In that 
folder, under the subdirectory structure of C:\chapter8- 


benchmark\srce\main\java\com\packt, is the MyBenchmark. java file. Maven created a 
benchmark class for us: 


Es Command Prompt 


r 
e Serial Number O8F-FF3F 
Directory «í 


{31/2017 


MyBenchmark. jav 


2 Dir(s) 
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Here are the contents of the MyBenchmark. java class created by the JMH Maven project 
creation process: 


/* 
* Copyright (c) 2014, Oracle America, Inc. 
* All rights reserved. 

* 
* Redistribution and use in source and binary forms, with or 
without 

* modification, are permitted provided that the following 

conditions are met: 


* Redistributions of source code must retain the above 
copyright notice, 
* this list of conditions and the following disclaimer. 


* Redistributions in binary form must reproduce the abov 
copyright 
* notice, this list of conditions and the following 
disclaimer in the 
* documentation and/or other materials provided with the 
distribution. 


* Neither the name of Oracle nor the names of its 
contributors may be used 
* to endorse or promote products derived from this software 
without 
specific prior written permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 

CONTRIBUTORS "AS IS" 
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
,IMITED TO, THE 
* IMPLIED WARRANTIES OF 
PARTICULAR PURPOSE 
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 
CONTRIBUTORS BE 


T 


T 


RCHANTABILITY AND FITNESS FOR A 


* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
EXEMPLARY, 
OR 

* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT OF 

* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; 


OR BUSINESS 


* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
WHETHER I 

* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
OTHERWISE) 
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* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE EV 
ADVISED OF 

* THE POSSIBILITY OF SUCH DAMAGI 

*/ 


EN IF 


fl 


package com.packt; 


import org.openjdk.jmh.annotations.Benchmark; 


public class MyBenchmark 

{ 
@Benchmark 
public void testMethod() 
{ 


// This is a demo/sample template for building your JMH 
benchmarks. 


//Edit as needed. 
// Put your benchmark code here. 


} 


Our next step is to modify the testMethod() so that there is something to test. Here is the 
modified method we will use for the benchmark test: 


@Benchmark 
public void testMethod() 
{ 
int total = 0; 
for (int i=0; i<100000; i++) 
{ 
total = total + (i * 2 ); 
} 


System.out.printin("Total: " + total); 
} 


With our code edited, we will navigate back to the project folder, C : \chapter8- 
benchmark, in our example, and execute mvn clean install at the command prompt. 
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You will see several repository downloads, source compilations, plugin installations and, 
finally the Build Success indicator, as shown here: 


Command Prompt 


C:\chapter8s-benchmark> 


You will now see .classpath and .project files as well as anew .settings and target 
subfolders in the project directory: 


E Command Prompt 


is 608F-FF3F 
Directory of C:\chapter8-benchmark 


) PM <DIR> 
69 PM 
PM 
PM 
PM 
PM 
3 PM 
6:03 PM 
:09 PM 
3 Fil 

6 Dir( 


: \chapter8-benchmark> 


If you navigate to the \target subfolder, you will see that our benchmarks. jar file was 
created. This JAR contains what we need to run our benchmarks. 
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We can update our MyBenchmark. java file in an IDE, such as Eclipse. Then, we can 
execute mvn clean install again to overwrite our files. After the initial time, our builds 
will be much faster, as nothing will need to be downloaded. Here is a look at the output 
from the build process other than the first time: 


E Command Prompt 


[INFO] 
[INFO] 
[INFO] 
[INFO] 
[INFO] 


[INFO] 

[INFO] 

[INFO] 

[INFO] (default-compile) @ 
[INFO] nges detecte ng module! 

[INFO] C C 

[INFO] 

[INFO] 


(default-testCompil 


(default-test) @ 


[ J (default-jar) @ 
[INFO] B - i mark\target\chapt 
[INFO] 

[INFO] 

[INFO] 

[INFO] 

[INFO] 


et\chapt 
[INFO] 
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Our last step is to run the benchmark tool. We can do that with the following command-- 
java -jar benchmarks. jar. Even for small benchmarks on simplistic code, as with our 
example, the benchmarks could take some time to run. There will likely be several iterations 
including warmups to provide a more concise and valid set of benchmark results. 


Our benchmark results are provided here. As you can see, the test ran for 8 minutes and 8 
seconds: 


Command Prompt 


Benchmarking options 


In the previous section, you learned how to run a benchmark test. In this section, we will 
look at the following configurable options for running our benchmarks: 


e Modes 
e Time units 
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Modes 


The output of our benchmark results, from the previous section, included a Mode column 
that had the value of thrpt which is short for throughput. This is the default mode and there 
are an additional four modes. All JMH benchmark modes are listed and described as 
follows: 


All Measures all other modes inclusively. 
Average This mode measures the average time for a single benchmark to run. 


Sample Time This mode measures the benchmark execution time and includes min and 
max times. 


Single Shot Time | With this mode, there is no JVM warm up and the test is to determine how 
long a single benchmark method takes to run. 

Throughput This is the default mode and measures the number of operations per second 
the benchmark could be run. 


To dictate which benchmark mode to use, you will modify your @Benchmark line of code to 
one of the following: 


@Benchmark @BenchmarkMode (Mode.All) 

@Benchmark @BenchmarkMode (Mode.Average) 
@Benchmark @BenchmarkMode (Mode. SamplmeTime) 
@Benchmark @BenchmarkMode (Mode.SingleShotTime) 
@Benchmark @BenchmarkMode (Mode. Throughput ) 


Time units 


In order to gain greater fidelity in benchmark output, we can designate a specific unit of 
time, listed here from shortest to longest: 


e NANOSECONDS 
e MICROSECONDS 
e MILLISECONDS 
e SECONDS 
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In order to make this designation, we simply add the following code to our @Benchmark 
line: 


@Benchmark @BenchmarkMode (Mode.Average) 
@OutputTimeUnit (TimeUnit .NANOSECONDS) 


In the preceding example, we have designated the average mode and nanoseconds as the 
time unit. 


Techniques for avoiding microbenchmarking 
pitfalls 


Microbenchmarking is not something that every developer will have to worry about, but for 
those that do, there are several pitfalls that you should be aware of. In this section we will 
review the most common pitfalls and suggest strategies for avoiding them. 


Power management 


There are many subsystems that can be used to help you manage the balance between 
power and performance (that is, cpufreq). These systems can alter the state of time during 
benchmarks. 


There are two suggested strategies to this pitfall: 


e Disable any power management systems before running tests 
e Run the benchmarks for longer periods 


OS schedulers 


Operating system schedulers, such as Solaris schedulers, help determine which software 
processes gain access to a system's resources. Use of these schedulers can result in 
unreliable benchmarking results. 


There are two suggested strategies to this pitfall: 


e Refine your system scheduling policies 
e Run the benchmarks for longer periods 
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Time sharing 


Time-sharing systems are used to help balance system resources. Use of these systems often 
results in irregular gaps between a thread's start and stop time. Also, CPU load will not be 
uniform and our benchmarking data will not be as useful to us. 


There are two suggested strategies to avoid this pitfall: 


e Test all code before running benchmarks to ensure things work as they should 


e Use JMH to measure only after all threads have started or all threads have 
stopped 


Eliminating dead-code and constant folding 


Dead-code and constant folding are often referred to as redundant code and our modern 
compilers are pretty good at eliminating them. An example of dead-code is code that will 
never be reached. Consider the following example: 


int value = 10; 
if (value != null) 
{ 
System.out.printin("The value is " + value + "."); 
} else 
{ 
System.out.printin("The value is null."); // This is 


a line of Dead-Cod 


In our preceding example, the line identified as dead-code is never reached since the 
variable value will never be equal to null. It is set to 10 immediately before the conditional 
if statement evaluates the variable. 
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The problem is that benchmarking code can sometimes be removed in the attempt to 
eliminate dead-code. 


Constant folding is the compiler operation that occurs when compile-time constraints are 
replaced with actual results. The compiler performs constant folding to remove any 
redundant runtime computations. In the following example, we have a final int 
followed by a second int based on a mathematical calculation involving the first int: 


static final int value = 10; 


int newValue = 319 * value; 


The constant folding operation would convert the two lines of the preceding code to the 
following: 


int newValue = 3190; 
There is one suggested strategy to this pitfall: 


e Use the JMH API support to ensure your benchmarking code is not eliminated 


Run-to-run variance 


There are a plethora of issues that can drastically impact the run-to-run variance in 
benchmarking. 


There are two suggested strategies to this pitfall: 


e Run the JVM multiple times within every subsystem 
e Use multiple JMH folks 
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Cache capacity 


Dynamic randomly accessed memory (DRAM) is very slow. This can result in very 
different performance results during benchmarking. 


There are two suggested strategies to this pitfall: 


e Run multiple benchmarks with varying problem sets. Keep track of your memory 
footprint during tests. 
e Use the @St ate annotation to dictate the JMH state. This annotation is sued to 
define the instance's scope. There are three states: 
e Scope.Benchmark: The instance is shared across all threads that 
are running the same test. 


e Scope.Group: One instance is allocated per thread group. 


e Scope. Thread: Each thread will have its own instance. This is the 
default state. 


Summary 


In this chapter, we learned that the JMH is a Java harness library for writing benchmarks for 
the JVM. We experimented with writing performance tests using Maven along with JMH to 
help illustrate the procedures of microbenchmarking with the new Java 9 platform. We 
started with a microbenchmarking overview, then dove deep into microbenchmarking with 
Maven, reviewed benchmarking options, and concluded with a few techniques for avoiding 
microbenchmarking pitfalls. 


In the next chapter, we will learn to write an application that is managing other processes 
and utilizes the modern process management API of the Java 9 platform. 
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In the previous chapter, we discovered the Java Microbenchmark Harness (JMH). We 
explored performance tests and how to write them using JMH, the Java library for writing 
benchmarks for the Java Virtual Machine. We started with an overview of 
microbenchmarking, then looked at microbenchmarking with Maven, reviewed 
benchmarking options, and concluded with techniques for avoiding microbenchmarking 
pitfalls. 


In this chapter, we will focus on the updates to the Process class and the new 
java.lang.ProcessHandle API. Prior to Java 9, managing processes in Java was never 
easy, because Java was rarely used to automate the controlling of other processes. The API 
was insufficient with some features lacking and some tasks needed to be solved in a system 
specific manner. For example, in Java 8, giving a process access to its own process identifier 
(PID) was an unnecessarily difficult task. 


In this chapter, the reader will gain all the knowledge that is needed to write an application 
that manages other processes and utilizes the modern process management API of Java. 


We will cover the following topics in this chapter: 


e What is and how to use the new ProcessHandle interface 

e How to get the PID of the current process 

e How to list different processes that run in the operating system 
e How to effectively wait for an external process to finish 

e How to terminate external processes 
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What are processes? 


In this section, we will review what processes are in the context of Java application 
programming. If you are already familiar with processes, you might consider skipping this 
section. 


Processes are executional units in the operating system. When you start a program, you 
start a process. When the machine boots the code, the first thing it does is, execute the boot 
process. This process then starts other processes that become the child of the boot process. 
These child processes may start other processes. This way, when the machine runs there are 
trees of processes running. When the machine does something, it is done in some code 
executing inside some process. The operating system also runs as several processes that 
execute simultaneously. Applications are executed as one or more processes. Most of the 
applications run as a single process but as an example, the Chrome browser starts several 
processes to do all the rendering and network communication operations that finally 
function as a browser. 


To get a better idea about what processes are, start the task manager on Windows or the 
Activity Monitor on OS X and click on the Process tab. You will see the different processes 
that currently exist on the machine. Using these tools, you can look at the parameters of the 
processes, or you can kill an individual process. 


The individual processes have their memory allocated for their work and they are not 
allowed to freely access each other's memory. 


The execution unit scheduled by the operating system is a thread. A process consists of one 
or more threads. These threads are scheduled by the operating system scheduler and are 
executed in time slots. 


With every operating system, processes have a process identifier, which is a number that 
identifies the process. No two processes can be active at a time, sharing the same PID. When 
we want to identify an active process in the operating system we use the PID. On Linux and 
other Unix-like operating systems, the kill command terminates a process. The argument 
to be passed to this program is the PID of the process, to terminate. Termination can be 
graceful. It is something like asking the process to exit. If the process decides not to, it can 
keep running. Programs can be prepared to stop upon such requests. For example, a Java 
application may add a Thread object calling the 

Runtime.getRuntime () .addShutdownHook (Thread t) method. The thread passed is 
supposed to start when the process is asked to stop and the thread can perform all tasks 
that the program has to do before it exits. However, there is no guarantee that it does start. 
It depends on the actual implementation. 
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The new ProcessHandle interface 


There are two new interfaces and also their implementations in Java 9 supporting the 
handling of operating system processes. One of them is ProcessHandle, the other one is 
ProcessHandle. Info, a nested interface of the prior. 


A ProcessHandle object identifies an operating system process and provides methods to 
manage the process. In prior versions of Java, this was possible only using operating system 
specific methods using the PID to identify the process. The major problem with this 
approach is that the PID is unique only while the process is active. When a process finishes, 
the operating system is free to reuse the PID for a new process. When we know only the 
PID of a process and check to see if the process is still running, what we are really doing is 
checking if there is an active process with that PID. Our process may be alive when we 
check it, but the next time our program queries the process state, it might be a different 
process. 


The desktop and server operating systems try not to reuse the PID values for as long as 
possible. On some embedded systems the operating system may only use 16-bit to store the 
PID. When only 16-bit values are used, there is a greater chance that the PIDs will be 
reused. We can avoid this problem using the ProcessHandle API. We can receive a 
ProcessHandle and can call the handle.isAlive() method. This method will return 
false when the process finishes. This works even if the PID was reused. 


Getting the PID of the current process 


We can gain access to the PID of the processes via the handle. The 

handle.getPid() method returns a Long representing the numerical value of the PID. 
Since it is safer to access the processes through the handle, the importance of this method is 
limited. It may come in handy when our code wants to give information about itself to some 
other management tool. It is a common practice for programs to create a file that has the 
numeric PID as the name of the file. It may be a requirement that a certain program does 
not run in multiple processes. In that case, the code writes its own PID file to a specific 
directory. If a PID file with that name already exists, processing stops. If the previous 
process crashed and terminated without deleting the PID file, then the system manager can 
easily delete the file and start the new process. If the program hangs, then the system 
manager can easily kill the dead process if s/he knows the PID. 


To get the PID of the current process, the call chain ProcessHandle.current (). 
getPid() canbe used. 
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Getting information about a process 


To get information about a process, we need access to the Info object of the process. This is 
available through a ProcessHandle. We use a call to the handle. info() method to 
return it. 


The Info interface defines query methods that deliver information about the process. These 
are: 


e command () returns an Optional<String> containing the command that was 
used to start the process 


e arguments () returns an Optional<String[]> that contains the arguments that 
were used on the command-line after the command to start the process 


e commandLine() returns an Optional<String> that contains the whole 
command-line 


e startInstant () returns an Opt ional<Instant>, which essentially represents 
the time the process was started 

e totalCpuDuration() returns an Optional<Duration>, which represents the 
CPU time used by the process since it was started 

e user () returns an Optional<String> that holds the name of the user the 
process belongs to 


The values returned by these methods are all Opt ional because there is no guarantee that 
the actual operating system or the Java implementation can return the information. 
However, on most operating systems it should work and the returned values should be 
present. 


The following sample code displays the information on a given process: 


import java.io.IOException; 
import java.time.Duration; 
import java.time.Instant; 
public class ProcessHandleDemonstration 
{ 
public static void main(String[] args) throws 
InterruptedException, IOException 
{ 
provideProcessInformation (ProcessHandle.current ())j; 
Process theProcess = new 
ProcessBuilder ("SnippingTool.exe") .start(); 
provideProcessInformation (theProcess.toHandle()); 
theProcess.waitFor(); 
provideProcessInformation (theProcess.toHandle()); 
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} 
static void provideProcessInformation(ProcessHandle theHandle) 
{ 
// get id 
long pid = ProcessHandle.current().pid(); 
// Get handle information (if available) 
ProcessHandle.Info handleInformation = theHandle.info(); 
// Print header 
System.out.print 
System.out.print 
System.out.print 
// Print the PID 
System.out.printlin("Process id (PID): " + pid); 
o 


in ( " | | EN 7 
1n("| INFORMATION ON YOUR PROCESS |"); 
in("| {\n"); 


System.out.printlin("Process Owner: " + 

handleInformation.user().orElse("")); 

// Print additional information if available 

System.out.printin("Command:" + 
handleInformation.command().orElse("")); 

String[] args = handleInformation.arguments().orElse 
(new String[]{}); 

System.out.printlin("Argument(s): "); 

for (String arg: args) System.out.printf("\t" + arg); 

System.out.printin("Command line: " + handleInformation. 
commandLine().orElse("")); 

System.out.printin("Start time: " + 
handleInformation.startInstant(). 
orElse(Instant.now()).toString()); 

System.out.printf("Run time duration: %sms%n", 
handleInformation.totalCpuDuration () 

.orElse (Duration.ofMillis(0)).toMillis()); 


} 


Here is the console output for the preceding code: 


fs Problems @ Javadoc B Declaration E) Console 32 
<terminated> ProcessHandleDemonstration [Java Application] C:\Program Files\Java\jre-9\bin\javaw.exe (Sep 14, 2017, 1:24:00 PM) 


Process id (PID): 6176 

Process Owner: DESKTOP-75PIVKB\elavi 
Command: 

Argument(s): 

Command line: 

Start time: 2017-@9-147T18:24:00.490Z 
Run time duration: 15ms 
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Listing processes 


Prior to Java 9, we did not have the means to obtain a list of active processes. With Java 9 it 
is now possible to get the processes in a stream. There are three methods that return a 
Stream<ProcessHandle>. One lists the child processes. The other lists all the descendants; 
the children and the children of those recursively. The third lists all the processes. 


Listing children 


To get the stream of process handles that can be used to control the children, the static 
method processHandle.children() should be used. This will create a snapshot of the 
children processes of the process represented by processHandle and create the Stream. 
Since processes are dynamic there is no guarantee that during the code execution, while our 
program attends to the handles, that all children processes are still active. Some of them 
may terminate and our process may spawn new children, perhaps from a different thread. 
Thus the code should not assume that each of the ProcessHandle elements of the stream 
represents an active and running process. 


The following program starts 10 command prompts in Windows and then counts the 
number of children processes and prints it to standard output: 


package packt.mastering.java9.process; 
import java.io.IOException; 


public class ChildLister { 
public static void main(String[] args) throws IOException { 
for (int i = 0; i < 10; i++) { 


new ProcessBuilder().command("cmd.exe").start(); 
} 
System.out.printin("Number of children :" + 
ProcessHandle.current ().children().count()); 


} 


Executing the program will result in the following: 


E C:\Windows\system32\cmd.exe 
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Listing descendants 


Listing the descendants is very similar to listing children, but if we call the 
processHandle.descendants () method then the St ream will contain all the children 
processes and the children processes of those processes and so on. The following program 
starts command prompts with command-line arguments so that they also spawn another 
cmd.exe that terminates: 


package packt.mastering.java9.process; 


import java.io.IOException; 
import java.util.stream.Collectors; 


public class DescendantLister { 
public static void main(String[] args) throws IOException { 
for (int i = 0; i < 10; i++) { 
new ProcessBuilder().command("cmd.exe","/K","cmd") . 
start(); 


} 
System.out.printin("Number of descendants: " + 
ProcessHandle.current () .descendants().count(); 


} 


Running the command a few times will result in the following, non-deterministic output: 


EA C:\Windows\system32\cmd.exe 
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The output clearly demonstrates that when the St ream of the descendants is created not all 
processes are alive. The sample code starts 10 processes and each of them starts another. 
The St ream does not have 20 elements because some of these sub-processes were 


terminated during processing. 


Listing all processes 


Listing all the processes is slightly different from listing descendants and children. The 
method allProcess () is static and returns a St ream of handles of all processes that are 
active in the operating system at the time of execution. 


The following sample code prints the process commands to the console that seem to be Java 
processes: 


package packt.mastering.java9.process; 
import java.lang.ProcessHandle.Info; 
public class ProcessLister { 
private static void out(String format, Object... params) { 
System.out.printin(String.format (format, params) ); 
} 
private static boolean looksLikeJavaProcess(Info info) { 
return info.command().isPresent() && 
info.command().get(). 
toLowerCase().indexOf ("java") != -1; 


public static void main(String[] args) { 
ProcessHandle.allProcesses(). 
map (ProcessHandle::info). 
filter(info -> looksLikeJavaProcess(info)). 
forEach ( 
(info) -> System.out.println ( 
info.command().orElse("—---") ) 


\; 
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The output of the program lists all the process commands that have the string java inside: 


E C:\Windows\system32\cmd.exe 


Your actual output may, of course, be different. 


Waiting for processes 


When a process starts another process, it may wait for the process many times because it 
needs the result of the other program. If the structure of the task can be organized in a way 
that the parent program can do something else while waiting for the child process to finish, 
then the parent process can invoke the isAlive() method on the process handle. Many 
times, the parent process has nothing to do until the spawned process finishes. Old 
applications implemented loops that called the Thread. sleep () method so CPU was not 
excessively wasted and from time to time the process was checked to see if it was still alive. 
Java 9 offers a much better approach to the waiting process. 


The ProcessHand1le interface has a method called onExit that returns a 
CompletableFuture. This class was introduced in Java 8 and makes it possible to wait for 
a task to be finished without looping. If we have the handle to a process we can simply call 
the handle. onExit () .join() method to wait until the process finishes. The get () 
method of the returned CompletableFuture will return the ProcessHand1e instance that 
was used to create it in the first place. 


We can call the onExit () method on the handle many times and each time it will return a 
different Complet ableFuture object, each related to the same process. We can call the 
cancel () method on the object but it will only cancel the CompletableFuture object and 
not the process and also does not have any effect on the other CompletableFuture objects 
that were created from the same ProcessHandle instance. 
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Terminating processes 


To terminate a process we can call the dest roy () method or the dest royForcibly () 
method on the ProcessHand_le instance. Both of these methods will terminate the process. 
The dest roy () method is expected to terminate the process gracefully executing the 
process shutdown sequence. In this case the shutdown hooks added to the run time are 
executed if the actual implementation supports the graceful, normal termination of 
processes. The dest royForcibly () method will enforce process termination, and in this 
case the shutdown sequence will not be executed. 


If the process managed by the handle is not alive then nothing happens when the code calls 
any of these methods. If there are any CompletableFuture objects created calling the 
onExit () method on the handle then they will be completed after the call to the 

destroy () or destroyForcefully() method when the process has terminated. This 
means that the CompletableFuture object will return from a join() or some similar 
method after some time when the process termination is complete and not immediately 
after destroy () or destroyForcefully() returned. 


It is also important to note that process termination may depend on many things. If the 
actual process that is waiting to terminate another does not have the right to terminate the 
other process then the request will fail. In this case the return value of the method is false. 
It is also important to understand that a return value of t rue does not mean that the 
process has actually terminated. It only means that the termination request was accepted by 
the operating system and that the operating system will terminate the process at some point 
in the future. This will actually happen rather soon, but not instantaneously and thus it 
should not be a surprise if the method isAlive() returns true for some time after the 
method destroy () or destroyForcefully() returned the value true. 


The difference between dest roy() and destroyForcefully () is implementation 
specific. The Java standard does not state that dest roy () does terminate the process letting 
the shutdown sequence be executed. It only requests the process be killed. Whether the process 
represented by this ProcessHandle object is normally terminated or not is implementation dependent 
(http: //download. java.net/java/jdk9/docs/api/java/lang/ProcessHandle. 
html#support sNormalTermination-—-). 


To learn more about ProcessHandle interface, visit http: //download. 
java.net/java/jdk9/docs/api/java/lang/ProcessHandle.html. 
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This is because some operating systems do not implement the graceful process termination 
feature. In such situations, the implementation of dest roy () is the same as calling 

dest royForcefully ().The system specific implementation of the interface 
ProcessHandle must implement the method supportsNormalTermination() that is 
true only if the implementation supports normal (not forceful) process termination. The 
method is expected to return the same value for all invocations in an actual implementation 
and should not change the return value during the execution of aJVM instance. There is no 
need to call the method multiple times. 


The following examples demonstrate process starting, process termination, and waiting for 
the process to terminate. In our example, we use two classes. This first class demonstrates 
the .sleep() method: 


package packt.mastering.java9.process; 


public class WaitForChildToBeTerminated 

{ 

public static void main(String[] args) 
throws InterruptedException 


{ 


Thread.sleep(10_000); 


} 
The second class in our example calls the Wait ForChildToBeTerminated class: 


package packt.mastering.java9.process; 


import java.io.IOException; 

import java.util.Arrays; 

import java.util.concurrent.CompletableFuture; 
import java.util.stream.Collectors; 


public class TerminateAProcessAfterWaiting { 
private static final int N = 10; 


public static void main(String[] args) 
throws IOException, InterruptedException { 


ProcessHandle ph[] = new ProcessHandle[N]; 

for (int i = 0; i < N; i++) 

{ 
final ProcessBuilder pb = ew ProcessBuilder(). 
command ("java", "-cp", "build/classes/main", 


"packt.mastering.java9.process. 
WaitForChildToBeTerminated") ; 
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Process p = pb.start(); 
ph[i] = p.toHandle(); 
} 
long start = System.currentTimeMillis(); 
Arrays.stream(ph) .forEach(ProcessHandle::destroyForcibly) ; 


CompletableFuture.allOf (Arrays.stream(ph) . 
map (ProcessHandle: :onExit). 

collect (Collectors.toList()). 

toArray (new CompletableFuture[ph.length])). 


join(); 
long duration = System.currentTimeMillis() - start; 
System.out.printin("Duration " + duration + "ms"); 


} 
} 


The preceding code starts 10 processes, each executing the program that sleeps 10 seconds. 
Then it forcibly destroys the processes, more specifically, the operating system is asked to 
destroy them. Our example joins the CompletableFuture that is composed from the array 
of CompletableFuture objects, which are created using the handles of the individual 
processes. 


When all the processes are finished then it prints out the measured time in milliseconds. 
The time interval starts when the processes are created and the process creation loop 
finished. The end of the measured time interval is when the processes are recognized by the 
JVM returning from the join() method. 


The sample code sets the sleeping time to 10 seconds. This is a more noticeable time period. 
Running the code twice and deleting the line that destroys the processes can result a much 
slower printout. Actually the measured and printed elapsed times will also show that 
terminating the processes has an effect. 


A small process controller application 


To summarize and put into use all that we have learned in this chapter we look at a sample 
process control application. The functionality of the application is very simple. It reads from 
a series of configuration file(s) parameters how to start some processes and then if any of 
them stops, it tries to restart the process. 
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Even a real life application can be created from this demo version. You can extend the set of 
parameters of the process with environment variable specifications. You can add default 
directory for the process, input and output redirection or even how much CPU a process is 
allowed to consume without the controlling application killing and restarting it. 


The application consists of four classes. 


e Main: This class that contains the public static void main method and is used to 
start up the daemon. 

e Parameters: This class contains the configuration parameters for a process. In 
this simple case it will only contain one field, the commandLine. If the application 
gets extended this class will contain the default directory, the redirections, and 
CPU use limiting data. 

e ParamsAndHandle: This class that is nothing else than a data tuple holding a 
reference to a Parameters object and also a process handle. When a process dies 
and gets restarted the process handle is replaced by the new handle, but the 
reference to the Parameters object never changes, it is configuration. 


e ControlDaemon: This class implements the interface Runnable and is started as 
a separate thread. 


In the code we will use most of the process API we discussed in the previous sections, 
Terminating processes and we will use a lot of threading code and stream operations. 
Understanding the threading work of the JVM is important independent of the process 
management also. It has, however emphasized importance when used together with the 
process API. 


Main class 


The main method takes the name of the directory from the command line argument. It 
treats this as relative to the current working directory. It uses a separate method from the 
same class to read the set of configurations from the files in the directory and then starts the 
control daemon. The following code if the main method of the program: 


public static void main(String[] args) throws IOException, 
InterruptedException 


{ 


// DemoOutput.out() simulated - implementation no shown 
DemoOutput.out (new File(".") .getAbsolutePath().toString()); 
if (args.length == 0) { 


System.err.printin("Usage: daemon directory"); 
System.exit(-1); 
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} 
Set<Parameters> params = parametersSetFrom(args[0]); 
Thread t = new Thread(new ControlDaemon (params) ); 
t.start(); 

} 


Although this is a daemon, we are starting it as a normal thread and not as a daemon 
thread. When a thread is set to be a daemon thread it will not keep the JVM alive. When all 
other non-daemon threads stop, the JVM will just exit and the daemon threads will be 
stopped. In our case, the daemon thread we execute is the only one that keeps the code 
running. After that was started the main thread has nothing more to do, but the JVM should 
stay alive, until it is killed by the operator issuing a Unix kill command or pressing 
Control + C on the command line. 


Getting the list of the files that are in the directory specified and getting the parameters 
from the file is simple using the new Files and Paths classes from the JDK: 


private static Set<Parameters> 
GetListOfFilesInDirectory (String directory) throws IOException 
{ 


return Files.walk (Paths.get (directory) ) 
-map (Path: :toFile) 
.filter(File::isFile) 
.map (file -> Parameters.fromFile(file) ) 
.collect (Collectors.toSet()); 
} 


We get a stream of the files in the form of Path objects, map it to File objects, then we filter 
out the directories if there are any in the configuration directory and map the remaining 
plain files to Parameters objects using the static method fromFile of the Parameters 
class. Finally, we return a Set of the objects. 


Parameters class 
Our Parameters class has a field and a constructor as listed as follows: 


final String[] commandLine; 


public Parameters (String[] commandLine) { 
this.commandLine = commandLine; 


} 
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The parameter class has two methods. The first method, get CommandLineSt rings, gets 
the command line strings from the properties. This array contains the command and the 
command line parameters. If it was not defined in the file then we return an empty array: 


private static String[] getCommandLineStrings (Properties props) 
{ 
return Optional 
.ofNullable(props.getProperty ("commandLine") ) 
.orElse("") 
-split("\\st"); 


} 


The second method is the static fromFile that reads the properties from a properties 
file: 


public static Parameters fromFile(final File file) 
{ 
final Properties props = new Properties (); 
try (final InputStream is = new FileInputStream(file)) { 
props.load(is); 
} catch (IOException e) { 
throw new RuntimeException(e); 


} 
return new Parameters (getCommandLineStrings (props) ); 


} 


If the set of parameters handled by the program is extended then this class should also be 
modified. 


The ParamsAndHandle class 


The ParamsAndHandle is a very simple class that holds two fields. One for the parameters 
and the other is the handle to the process handle that is used to access the process started 
using the parameters: 


public class ParamsAndHandle 
{ 
final Parameters params; 
ProcessHandle handle; 


public ParamsAndHandle (Parameters params, 
ProcessHandle handle) { 
this.params = params; 
this.handle = handle; 
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public ProcessHandle toHandle() { 
return handle; 
} 
} 


Since the class is closely tied to the Cont rolDaemon class from where it is used there is no 
mutator or accessor associated with the field. We see the two classes as something inside the 
same encapsulation boundaries. The toHandle method is there so that we can use it as a 
method handle, as we will see in the next chapter. 


The ControlIDaemon class 


The Cont rolDaemon class implements the Runnable interface and is started as a separate 
thread. The constructor gets the set of the parameters that were read from the properties 
files and converts them to a set of ParamsAndHandle objects: 


private final Set<ParamsAndHandle> handlers; 


public ControlDaemon(Set<Parameters> params) { 
handlers = params 
. stream () 
-map( s -> new ParamsAndHandle(s,null) ) 
.collect (Collectors.toSet()); 

} 


Because the processes are not started at this point, the handles are all nu11. The run () 
method starts the processes: 


@Override 
public void run() { 
try { 
for (ParamsAndHandle pah : handlers) { 
log.log(DEBUG, "Starting {0}", pah.params) ; 
ProcessHandle handle = start (pah.params) ; 
pah.handle = handle; 
} 
keepProcessesAlive(); 
while (handlers.size() > 0) { 
allMyProcesses().join(); 
} 
} catch (IOException e) 


{ 
log.log(ERROR, e); 
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Processing goes through the set of parameters and uses the method (implemented in this 
class later) to start the processes. The handles to each process get to the ParamsAndHandle 
object. After that, the keepProcessesAlive method is called and waits for the processes to 
finish. When a process stops it gets restarted. If it cannot be restarted it will be removed 
from the set. 


The allMyProcesses method (also implemented in this class) returns a 
CompletableFuture that gets completed when all the started processes have stopped. 
Some of the processes may have been restarted by the time the join() method returns. As 
long as there is at least one process running, the thread should run. 


Using the CompletableFuture to wait for the processes and the while loop, we use 
minimal CPU to keep the thread alive so long as long there is at least one process we 
manage running, presumably even after a few restarts. We have to keep this thread alive 
even if it does not use CPU and executes no code most of the time to let the 
keepProcessesAlive() method do its work using CompletableFutures. The method is 
shown in the following code snippet: 


private void keepProcessesAlive () 
{ 
anyOfMyProcesses () 
-thenAccept (ignore -> { 
restartProcesses(); 
keepProcessesAlive(); 
H); 


} 


The keepProcessesAlive () method calls the anyOfMyProcesses () method that returns 
a CompletableFuture, which is completed when any of the managed processes exits. The 
method schedules to execute the lambda passed as an argument to the thenAccept () 
method for the time the CompletableFuture is completed. The lambda does two things: 


e Restarts the processes that are stopped (probably only one) 
e Calls the keepProcessesAlive() method 


It is important to understand that this call is not performed from within the 
keepProcessesAlive() method itself. This is not a recursive call. This is scheduled as a 
CompletableFuture action. We are not implementing a loop in a recursive call, because 
we would run out of stack space. We ask the JVM executors to execute this method again 
when the processes are restarted. 
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It is important to know that the JVM uses the default ForkJoinPool to schedule these tasks 
and this pool contains daemon threads. That is the reason we have to wait and keep the 


method running because that is the only non-daemon thread that prevents the JVM from 
exiting. 


The next method is restartProcesses(): 


private void restartProcesses () 
{ 
Set<ParamsAndHandle> failing = new HashSet<>(); 
handlers.stream() 
.filter (pah -> !pah.toHandle().isAlive() ) 
.-forEach(pah -> { 
try { 
pah.handle = start (pah.params) ; 
} catch (IOException e) { 
failing.add(pah) ; 


} 
})i 
handlers.removeAll (failing); 


} 


This method starts the processes that are in our set of managed processes and which are not 
alive. If any of the restarts fail it removes the failing processes from the set. (Be aware not to 
remove it in the loop to avoid ConcurrentModificationException.) 


The anyOfMyProcesses() and allMyProcesses() methods are using the auxiliary 
completableFuturesOfTheProcessesand() method and are straight forward: 


private CompletableFuture anyOfMyProcesses () 
{ 


return CompletableFuture.anyOf ( 
completableFuturesOfTheProcesses())j; 


private CompletableFuture allMyProcesses() { 
return CompletableFuture.allOf ( 
completableFuturesOfTheProcesses ()); 
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The completableFuturesOfTheProcesses () method returns an array of 
CompletableFutures created from the currently running managed processes calling their 
onExit () method. This is done in a compact and easy to read functional programming 
style, as shown here: 


private CompletableFuture[] completableFuturesOfTheProcesses () 
{ 
return handlers.stream() 
.map (ParamsAndHandle: :toHandle) 
.map (ProcessHandle: :onExit) 
-collect (Collectors.toList () ) 
.toArray (new CompletableFuture[handlers.size()]); 


} 


The set is converted to a stream, mapped to a stream of ProcessHandle objects (this is 
why we needed the toHandle() method in the ParamsAndHandle class). Then the handles 
are mapped to CompletableFuture stream using the onExit () method and finally we 
collect it to a list and convert to an array. 


Our last method to complete our sample application is as follows: 


private ProcessHandle start (Parameters params) 
throws IOException { 
return new ProcessBuilder (params.commandLine) 
start () 
.toHandle(); 


} 


This method starts the process using a ProcessBuilder and returns the ProcessHandle 
so that we can replace the old one in our set and manage the new process. 


Summary 


In this chapter we discussed how Java 9 better enables us to manage processes. Prior to Java 
9, process management from within Java required OS specific implementations and was 
less than optimal in terms of CPU use and coding practice. The modern API, with new 
classes like ProcessHandle, makes it possible to handle almost all aspects of processes. 
We listed the new API, and had simple example codes for the use of each of them. In the 
second half of the chapter we put together a whole application managing processes where 
the learned API was put into practice. 


In the next chapter, we will take a detailed look at the new Java Stack Walking API released 
with Java 9. We will use code samples to illustrate how to use the API. 
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Java 9 comes with a new stack walker API that lets the program walk the calling stack. This 
is a very special functionality that is rarely needed by ordinary programs. The API can be 
useful for some very special cases--for functionality that is delivered by framework. So, if 
you want an efficient means of stack walking that gives you filterable access to stack trace 
information, you will enjoy this new stack walker API. 


The API gives fast and optimized access to the call stack, implementing lazy access to the 
individual frames. 


In this chapter, we cover the following topics: 


e Overview of the Java Stack 

e The importance of stack information 
e Using StackWalker 

e The StackFrame 

e Performance 


Overview of the Java Stack 


Before we dive into the stack walker, let's start by covering the Java Stack. This is basic stack 
information, not specific to the stack walker. 


The Java runtime has a class named Stack, which can be used to store objects using the last- 
in-first-out (LIFO) policy. 
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When arithmetic expressions are calculated they are done using a stack. If we add A and B 
in our code first A is pushed on the Operand Stack, then B is pushed on the Operand Stack 
and finally the addition operation is executed, which fetches the two topmost elements of 
the Operand Stack and pushes the result, A + B there. 


The JVM is written in C and executes calling C functions and returning from there. This 
call-return sequence is maintained using the Native Method Stack just like any other C 
program. 


Finally, when the JVM creates a new thread it also allocates a call stack containing frames 
that in turn contain the local variables, reference to the previous frame, and reference to the 
class that contains the executing method. When a method is invoked a new frame is created. 
The frame is destroyed when a method finishes its execution, in other words, returns or 
throws an exception. This stack, the Java Virtual Machine Stack, is the one that the stack 
walker API manages. 


The importance of stack information 


Generally speaking we need the stack information when we want to develop caller 
dependent code. Having information about the caller allows our code to make decisions 
based on that information. In general practice, it is not a good idea to make functionality 
dependent on the caller. Information that affects the behavior of a method should be 
available via parameters. Caller dependent code development should be fairly limited. 


The JDK accesses stack information with native methods that are not available to Java 
applications. The SecurityManager is a class that defines an application's security policy. 
This class checks that the caller of a reflection API is allowed to access the non-public 
members of another class. To do that it has to have access to the caller class and it does that 
through a protected native method. 


This is an example of implementing some security measures without having to walk 
through a stack. We open our code for external developers to use it as a library. We also call 
methods of classes provided by the library user and they may call back to our code. There is 
some code that we want to allow library users to call but only if they were not called from 
our code. If we did not want to allow some of the code to be accessed directly by the library 
using code we could use Java 9's modular structure not exporting the package containing 
the classes not to be invoked. This is the reason we set the extra condition that the code is 
available for the callers from outside, except if they were called by our code: 
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protected code 


Another example is when we want to get access to a logger. Java applications use many 
different loggers and the logging system is usually very flexible so that the output of the 
different loggers can be switched on and off based on the actual need to introspect into the 
code. The most common practice is to use a different logger for each class and the name of 
the logger is usually the name of the class. The practice is so common that the logging 
framework even provides logger access methods that accept the reference to the class itself 
instead of the name. It essentially means that the call to get the handle of a logger looks 
something like the following: 


private static final Logger LOG = Logger.getLogger (MyClass.class) ; 


A problem can arise when we create new classes from existing classes if we forget to alter 
the name of the class name in the call for getting a new logger. This is not a serious problem, 
but it is common. In that case our code will use the logger of the other class and it will 
actually work, but may create confusion when we analyze the log files. It would be much 
nicer if we had a method that returns the logger that is named as the class of the caller. 


Let's continue our exploration of stack information in the next two sections with code 
snippet examples. 
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Example - Restricting callers 


In this section we develop a sample library with two methods. The hello () method prints 
hello to the standard output. The cal1Me () method accepts a Runnable as an argument 
and runs it. The first method however is restricted. It executes only if the caller is purely 
outside of the library. It throws an IllegalCallerExcept ion if the caller obtained the 
control in a way that the library was calling out, presumably via the second method 
invoking the passed Runnable. The implementation of the API is simple: 


package packt.java9.deep.stackwalker.myrestrictivelibrary; 
public class RestrictedAPI { 
public void hello(){ 
CheckEligibility.itIsNotCallBack (); 
System.out.printin("hello"); 


} 
public void callMe(Runnable cb) { 
eb. run (); 
} 
} 


The code that performs the eligibility checking is implemented in a separate class to keep 
things simple. We will examine that code shortly, but before that we look at the main code 
we use to start the demonstration. The main program code we use to demonstrate the 
functionality is the following: 


package packt.java9.deep.stackwalker.externalcode; 


import 
packt.java9.deep.stackwalker.myrestrictivelibrary.RestrictedAPI; 


public class DirectCall { 


public static void main(String[] args) { 
RestrictedAPI api = new RestrictedAPI(); 
api.hello(); 
api.callMe(() -> { 
api.hello(); 
J); 
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This code creates an instance of our API class and then directly invokes the hello () 
method. It should work and should print the characters he11o on screen. The next code line 
asks the callMe() method to call back the Runnable provided in form of a lambda 


expression. In this case the call will fail, because the caller is outside but was called from 
inside the library. 


Let's now look at how the eligibility check is implemented: 


package packt.java9.deep.stackwalker.myrestrictivelibrary; 


import static java.lang.StackWalker.Option.RETAIN_CLASS REFERENCE; 


public class CheckEligibility { 
private static final String packageName 
= CheckEligibility.class.getPackageName (); 


private static boolean notInLibrary(StackWalker.StackFrame f) { 
return !inLibrary(f); 


} 


private static boolean inLibrary(StackWalker.StackFrame f) { 
return f.getDeclaringClass().getPackageName () 
.equals (packageName) ; 


public static void itIsNotCallBack() { 
boolean eligible = StackWalker 
.getInstance (RETAIN_CLASS_REFERENCE) 
.walk (s -> s.dropWhile(CheckEligibility::inLibrary) 
.dropWhile (CheckEligibility::notInLibrary) 
.count () == 


i 
if (!eligible) { 
throw new IllegalCallerException(); 


} 


} 


The it IsNotCallBack() method is the one called from the hello () method. This method 
creates a stack walker and invokes the walk () method. The argument of the walk () 
method is a Function that converts a Stream of StackFrame objects to some other value 
that the walk () method will return. 


At first this argument setting might seem complex and difficult to understand. It would be 
more logical to return a St ream that provides the StackFrame objects instead of forcing the 
caller to define a Function that will get this as an argument. 
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The sample code uses a lambda expression to define the Funct ion as an argument to the 
walk() method. The argument to the lambda expression s is the stream. Since the first 
element of this stream is the actual call we drop it. Because these calls should also be 

refused if the caller is not eligible even though the call to method hello () was through 
some other class and method that is already inside the library, we drop all elements from 
the frame that belong to classes inside the package of the class CheckEligibility. This 
package is packt . java9.deep.stackwalker.myrestrictivelibrary and in the code 
this string is stored in the field packageName. The resulting stream contains only the 
StackFrame objects that are from outside of the library. We drop these also until the stream 
exhausts or until we find a StackFrame that again belongs to the library. If all elements 
were dropped we are good. In this case the result of count () is zero. If we find some class 
in the StackFrame that belongs to the library it means that the outside code was called 
from the library and in this case we have to refuse working. In this case the variable eligible 
will be false and we throw an exception, as can be seen in the following screenshot: 


@ DirectCall.java © CheckEligibility.java 
DirectCall|| main() || -> Runnable 
package packt. java9. deep. stackwalker.externalcode; 


import packt. java9.deep.stackwalker.myrestrictivelibrary.RestrictedAPI; 


public class DirectCall { 


public static void main(String[] args) { 
RestrictedAPI api = new RestrictedAPI(); 
api.hello(); 
api.callMe(() -> 
api.hello() ;] 


DirectCall 

/Library/Java/JavaVirtualMachines/jdk-9. jdk/Contents/Home/bin/java “-javaagent:/Applications/IntelliJ IDEA CE 

Exception in thread "main" java. lang.IllegalCallerException 

hello 
at stackwalker/packt. java9.deep.stackwalker.myrestrictivelibrary.CheckEligibility. itIsNotCallBack(CheckEligibility. java:31) 
at stackwalker/packt. java9. deep. stackwalker.myrestrictivelibrary.RestrictedAPI.hello(RestrictedAPL. java:6) 
at stackwalker/packt. java9. deep. stackwalker. externalcode.DirectCall. LambdaSmains@(DirectCalL. java:11) 
at stackwalker/packt. java9.deep.stackwalker.myrestrictivelibrary.RestrictedAPI.callMe(RestrictedAPI. java:11) 
at stackwalker/packt. java9. deep. stackwalker. externalcode.DirectCall.main(DirectCall. java:10) 


Process finished with exit code 1 
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Example - Getting logger for caller 


To get a logger, Java 9 has anew API. Using this API a module can provide an 
implementation for the service LoggerF inder, which in turn can return a Logger 
implementing the get Logger () method. This eliminates the dependency of libraries on 
specific loggers or logger facades, which is a huge advantage. The smaller but still annoying 
issue requiring us to write the name of the class again as the parameter to the method 
getLogger () is still there. 


To avoid this cumbersome task, we create a helper class that looks up the caller class and 
retrieves the logger that is suitable for the caller class and module. Because in this case there 
is no need for all the classes referenced in the stack trace we will call the 
getCallerClass() method of the StackWalker class. We create a class named Labrador 
in the package packt.java9.deep.stackwalker.logretriever: 


package packt.java9.deep.stackwalker.logretriever; 


import java.lang.System. Logger; 
import java.lang.System. LoggerFinder; 


import static java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE; 


public class Labrador { 
public static Logger retrieve() { 
final Class clazz = StackWalker 


.get Instance (RETAIN_CLASS_REFERENCE) 
.getCallerClass(); 

return LoggerFinder.getLoggerFinder () .getLogger ( 
clazz.getCanonicalName(), clazz.getModule()); 


} 


Before Java 9 the solution for this issue was getting the StackTrace array from the Thread 
class and looking up the name of the caller class from there. Another approach was 
extending the SecurityManager that has a protected method getClassContext () that 
returns an array of all the classes on the stack. Both solutions walk through the stack and 
compose an array although we only need one element from the array. In case of logger 
retrieval it may not be a significant performance penalty since loggers are usually stored in 
private static final fields and thus are initialized once per class during class 
initialization. In other use cases the performance penalty may be significant. 


After we have seen two examples we will look at the details of StackWalker inner 
working. 
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Working with StackWalker 


In this section you will become more familiar with how to work with StackWalker. We 
will explore the following topics in this section: 


e Getting an instance of StackWalker 
e Stack walking options 


Getting an instance of StackWalker 


To perform the walking over the stack elements we need an instance of the stack walker. To 
do that, we invoke the get Instance () method. As shown here, there are four overloaded 
versions of this method: 


e static StackWalker getInstance 


() 

e static StackWalker getInstance(StackWalker.Option option) 
e static StackWalker getInstance(Set<StackWalker.Option> options) 
e static StackWalker getInstance(Set<StackWalker.Option> options, 
int estimateDepth) 


The first version does not take any arguments and returns a StackWalker instance that will 
let us walk through normal stack frames. This is usually what we would be interested in. 
The other versions of the method accept a StackWalker. Option value or values. The 
enum StackWalker.Option, as the name suggests, is inside the class StackWalker and 
has three values: 


e RETAIN_CLASS_REFERENCE 
e SHOW_REFLECT_FRAMES 
e SHOW_HIDDEN_FRAMES 


These enum options have self-descriptive names and are explained in the next sections. 


RETAIN CLASS REFERENCE 


If we specify the first option enum constant, RETAIN_CLASS_REFERENCE, as an argument 
to the get Instance () method then the returned instance grants us access to the classes 
that the individual stack frames reference during the walking. 


[ 234 ] 


www.EBooksWorld.ir 


Fine-Grained Stack Tracing 


SHOW_REFLECT_FRAMES 


The SHOW_REFLECT_FRAMES enum constant will generate a walker that includes the frames 
that source from some reflective calling. 


SHOW_HIDDEN_FRAMES 


Finally the enum constant option, SHOW_HIDDEN_FRAMES will include all the hidden frames, 
which contain reflective calls as well as call frames that are generated for lambda function 
calls. 


Here is a simple demonstration of reflective and hidden frames: 


package packt; 
import static java.lang.StackWalker.Option.SHOW_HIDDEN_FRAMES; 
import static java.lang.StackWalker.Option.SHOW_REFLECT_FRAMES; 
public class Main { 


The main method allowing us to execute this code directly calls the method simpleCall1 (): 


public static void main(String[] args) { 
simpleCall(); 
} 


The method simpleCall1() simply calls on as the name suggests: 


static void simpleCall() { 
reflectCall(); 
} 


The next method in the chain is a bit more complex. Although this also only calls the next 
one, it does so using reflection: 


static void reflectCall() { 
try { 
Main.class.getDeclaredMethod("lambdaCall", 
new Class[0]) 
-invoke (null, new Object [0]); 
} catch (Exception e) { 
throw new RuntimeException(); 


} 
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In this next example, we have a method that calls using a lambda: 


static void lambdaCall() { 
Runnable r = () —> { 
walk(); 
Fý 
Yr. tun ():; 


} 


The last method before the actual walking is called walk (): 


static void walk() { 
noOptions(); 
System.out.printin(); 
reflect (); 
System.out.printin(); 
hidden (); 

} 


The preceding walk () method calls three methods, one after the other. These methods are 
very similar to each other and provided here: 


static void noOptions() { 
StackWalker 
-getInstance () 
.forEach(System.out::println); 


static void reflect() { 
StackWalker 
.getInstance (SHOW_REFLECT_FRAMES) 
.forEach (System.out::printlin); 


static void hidden() { 
StackWalker 
// shows also reflect frames 
.-getInstance (SHOW_HIDDEN_FRAMES) 
.forEach(System.out::println); 
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The preceding three methods print out the frames to the standard output. They use the 
forEach() method of the stack walker. Here is the output of the stack walking program: 


stackwalker/packt .Main.noOptions (Main. java: 45) 
stackwalker/packt .Main.walk (Main. java: 34) 
stackwalker/packt .Main. lambda$lambdaCa11$0 (Main. java: 28) 
stackwalker/packt .Main.lambdaCall1 (Main. java: 30) 
stackwalker/packt .Main.reflectCall (Main. java:19) 
stackwalker/packt .Main.simpleCall1 (Main. java:12) 
stackwalker/packt .Main.main (Main. java: 8) 


This output only contains the frames that belong to calls that are in our code. The main () 
method calls simpleCall(), which calls reflectCall (), that in turn calls 
lambdaCal1(), which calls a lambda expression, that calls walk () and so on. The fact that 
we did not specify any option does not delete the lambda call from the stack. We performed 
that call, thus it must be there. What it deletes are the extra stack frames that are needed by 
the JVM to implement the lambda. We can see on the next output, when the option was 
SHOW_REFLECT_FRAMES, that the reflective frames are already there: 


stackwalker/packt .Main. reflect (Main. java:58) 
stackwalker/packt .Main.walk (Main. java: 36) 
stackwalker/packt .Main. lambda$lambdaCa11$0 (Main. java: 28) 

stackwalker/packt .Main.lambdaCall1 (Main. java: 30) 
java.base/jdk.internal.reflect .NativeMethodAccessorImp1.invoke0 (Native 
Method) 

java.base/jdk.internal.reflect .NativeMethodAccessorImp1. invoke (NativeMethod 
AccessorImpl. java: 62) 

java.base/jdk.internal.reflect .DelegatingMethodAccessorImpl1. invoke (Delegati 
ngMethodAccessoriImp1. java: 43) 
java.base/java.lang.reflect .Method. invoke (Method. java: 547) 
stackwalker/packt .Main.reflectCall (Main. java:19) 

stackwalker/packt .Main.simpleCall (Main. java:12) 
stackwalker/packt .Main.main (Main. java: 8) 


In this case the difference is that we can see that the call from the reflectCall() method 
to lambdaCall1() method is not direct. The reflectCall() method calls the invoke () 
method that calls another method of the same name defined in a different class that in turn 
calls the invoke0 () method, which is a native method provided by the JVM. After that we 
finally get to the LambdaCa11 () method. 


In the output we can also see that these reflective calls belong to the module java.base 
and not our stackwalker module. 
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If we include the hidden frames in addition to the reflective frames, specifying the option 
SHOW_HIDDEN_FRAMES, then we will see the following output: 


stackwalker/packt .Main. hidden (Main. java: 52) 
stackwalker/packt .Main.walk (Main. java: 38) 
stackwalker/packt .Main. lambda$lambdaCal11$0 (Main. java: 28) 

stackwalker/packt .Main$$Lambda$46/269468037.run (Unknown Source) 
stackwalker/packt .Main.lambdaCall1 (Main. java: 30) 
java.base/jdk.internal.reflect .NativeMethodAccessorImpl1.invoke0 (Native 
Method) 

java.base/jdk.internal.reflect .NativeMethodAccessorImp1. invoke (NativeMethod 
AccessorImpl. java: 62) 

java.base/jdk.internal.reflect .DelegatingMethodAccessorImpl1. invoke (Delegati 
ngMethodAccessorImp1. java: 43) 
java.base/java.lang.reflect .Method. invoke (Method. java:547) 
stackwalker/packt .Main.reflectCall (Main. java:19) 

stackwalker/packt .Main.simpleCall (Main. java:12) 
stackwalker/packt .Main.main (Main. java: 8) 


This includes an extra hidden frame that the JVM is using to execute the lambda call. In 
addition, the reflective frames are also included. 


Final thoughts on enum constants 


We can also specify more than one option giving a set of the options. The simplest way of 
doing that is to use the static of () method of the java.util.Set interface. This way the 
RETAIN_CLASS_REFERENCE option can be combined with either the 
SHOW_REFLECT_FRAMES option or the SHOW_HIDDEN_FRAMES option. 


Although it is technically possible to combine SHOW_REFLECT_FRAMES and 
SHOW_HIDDEN_FRAMES as an option set, there is really no advantage in doing that. The 
latter includes the first, so the combination of the two is exactly same as the second. 


Accessing classes 


When we want to access the class objects during a stack walk, we have to specify the 
RETAIN_CLASS_REFERENCE option. Although the StackFrame interface defines the 
getClassName () method, that could be used to access a class of the name using the 
Class. forName() method, doing so would not guarantee that the class the StackFrame 
object refers to was loaded by the same class loader as the code calling Class. forName(). 
In some special cases, we could end up with two different classes of the same name loaded 
by two different class loaders. 
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When the option is not used during the creation of the StackWalker instance then the 
methods that otherwise return a class object will throw an 
UnsupportedOperationException exception. That way getDeclaringClass () cannot 
be used on the StackFrame and getCallerClass() onthe StackWalker. 


Walking methods 


The StackWalker defines the forEach() method that expects a Consumer (preferably in 
the form of a lambda expression) that is invoked for each element of the stack trace walking 
up the stack. The argument to the Consumer method is a StackFrame object. 


Although a method named forEach is also defined by the St ream interface and the 
method walk () passes a St ream object to the Function it gets as argument, we should not 
confuse the two. The forEach() method of StackWalker is a simpler, and most of the 
time less effective way to get through all the elements of the stack trace. 


It is less effective, in most cases, because it forces the StackWalker instance to get all the 
elements of the stack trace so that the forEach () method can traverse through each 
element to the end. If we know that we will not traverse through the stack trace to the end 
we should use the walk () method that is accessing the stack the lazy way and thus leave 
more room for performance optimization. 


The StackWalker class has the walk () method, which is the defining method that makes it 
a walker. The method accepts a Function that is called by the StackWalker. The return 
value of the walk () method will be the object returned by the Funct ion. The argument to 
the Functionisa Stream<StackFrame> that delivers the stack frames. The first frame is 
the one that contains the walk () method call, the next is the one that was calling method 
that contains the call to walk (), and so on. 


The Function can be used to calculate some value based on the StackFrame objects that 
come from the stream and decide if a caller is eligible calling our code or not. 
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You might ponder, after reviewing the walk () method that needs a Function that in turn 
gets a Stream<StackFrame> as argument, why it is so complicated. We might wish we 
could get a Stream<StackFrame> from the StackWalter instance directly. The simplest 
approach would be to pass the stream back from the Funct ion. Consider the following 
example: 


// EXAMPLE OF WHAT NOT TO DO!!!! 
public static void itIsNotCallBack() { 
Stream<StackWalker.StackFrame> stream = 
StackWalker 
.get Instance (RETAIN_CLASS_REFERENCE) 
.walk (s -> s); 
boolean eligible = // YOU GET EXCEPTION!!!! 
stream.dropWhile (CheckEligibility::inLibrary) 
.dropWhile (CheckEligibility::notInLibrary) 
.count () == 0; 
if (!eligible) { 
throw new IllegalCallerException(); 


} 


} 


What we were doing is simply returning the stream directly from the walker call and 
walking through it afterwards doing the same calculation. Our results are an 
IllegalStateException exception instead of the eligibility check. 


The reason for that is that the implementation of the StackWalker is highly optimized. It 
does not copy the whole stack to provide source information for the stream. It works from 
the actual, living stack. To do that it has to be sure that the stack is not modified while the 
stream is in use. This is something very similar to the 
ConcurrentModificationException that we might get if we alter a collection while we 
iterate over it. If we passed the stream up in the call stack and then wanted to get the 
StackFrame out of it, the stream would try to get the information from the stack frame that 
is long gone, since we returned from the method that it belonged to. That way the 
StackWalker does not make a snapshot of the whole stack but rather it works from the 
actual one and it must ensure that the part of the stack it needs does not change. We may 
call methods from the Function and that way we can dig deeper in the call chain but we 
cannot get higher while the stream is in use. 


Also do not try to play other tricks, like extending the StackWalker class. You cannot. It is 
a final class. 
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StackFrame 


In previous sections, we iterated through the StackFrame elements, and provided sample 
code snippets, but did not take the time to examine it more closely. StackFrame is an 
interface defined inside the StackWalker class. It defines accessors, and a converter that 
can be used to convert the information to StackTraceElement. 


The accessors the interface defines are the following: 


getClassName () will return the binary name of the class of the method 
represented by the StackFrame. 

getMethodName () will return the name of the method represented by the 
StackFrame. 

getDeclaringClass() will return the class of the method represented by the 
StackFrame. If the Option. RETAIN_CLASS_REFERENCE was not used during 
the creation of the StackWalker instance then the method will throw 
UnsupportedOperationException. 


getByteCodeIndex () gets the index to the code array containing the execution 
point of the method represented by the StackFrame. The use of this value can be 
helpful during bug hunting when looking at the disassembled Java code that the 
command line tool javap can give us. The programmatic use of this value can 
only be valuable for applications that have direct access to the byte code of the 
code, java agents or libraries that generate byte code during run-time. The 
method will return a negative number in case the method is native. 
getFileName() returns the name of the source file the method represented by 
the StackFrame was defined. 


getLineNumber () returns the line number of the source code. 


isNativeMethod() returns true if the method represented by the StackFrame 
is native and false otherwise. 


The StackFrame does not provide any means to access the object that the method belongs 
to. You cannot access the arguments and the local variables of the method represented by 
the StackFrame and there is no other way you can accomplish that. This is important. Such 
access would be too invasive and is not possible. 
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Performance 


Our coverage of StackWalker would not be complete without a look at performance 
considerations. 


StackWalker is highly optimized and does not create huge memory structures that go 
unused. That is the reason why we have to use that Function passed to the method 
walker () as an argument. This is also the reason why a StackTrace is not automatically 
converted to a StackTraceElement when created. This only happens if we query the 
method name, the line number of the specific StackTraceElement. It is important to 
understand that this conversion takes a significant amount of time and if it was used for 
some debug purpose in the code it should not be left there. 


To make the StackWalker even faster we can provide an estimate about the number of 
StackFrame elements that we will work with in the stream. If we do not provide such an 
estimate, the current implementation in the JDK will use eight StackFrame objects pre- 
allocated and when that is exhausted, the JDK will allocate more. The JDK will allocate the 
number of elements based on our estimate unless we estimate a value larger than 256. In 
that case, the JDK will use 256. 


Summary 


In this chapter, we learned how to use the StackWalker and provided example code. Our 
detailed review of the API included different usage scenarios, options, and information. We 
explained the API's complexity and shared how and how not to use the class. We closed 
with some related performance issues that the user has to be aware of. 


In our next chapter, we will cover over a dozen Java Enhancement Proposals that were 
incorporated in the Java 9 platform. The featured changes will cover a wide range of tools 
and updates to APIs that are aimed at making developing with Java easier and the ability to 
create optimized Java applications. We will look at the new HTTP client, changes to the 
Javadoc and Doclet API, the new JavaScript parser, JAR and JRE changes, the new Java- 
level JVM compiler interface, support for TIFF images, platform logging, XML catalog 
support, collections, new platform-specific desktop features, and enhancements to method 
handling and the depreciation annotation. 
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New Tools and Tool 
Enhancements 


In the previous chapter, we explored Java 9's new stack walker API and learned how it 
enables Java applications to walk the calling stack. This is a specialized functionality that is 
not often implemented in Java applications. That being said, the API may be good for some 
very special cases, such as for functionality that is delivered by a framework. You learned 
that if you develop framework-supporting application programming and you want code 
that depends on the caller context, then the stack walker API is for you. We also discovered 
that the API gives fast and optimized access to the call stack, implementing lazy access to 
the individual frames. 


In this chapter, we will cover 16 Java Enhancement Proposals (JEPs) that were 
incorporated into the Java 9 platform. These JEPs cover a wide range of tools and updates to 
APIs to make developing with Java easier, with greater optimization possibilities for our 
resulting programs. 


Our review of new tools and tool enhancements will include the following: 


e The new HTTP client 

e Javadoc and the Doclet API 

e mJRE changes 

e JavaScript parser 

e Multi-release JAR files 

e The Java-level JVM compiler interface 
e TIFF support 


Platform logging 
e XML Catalogs 
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e Collections 

e Platform-specific desktop features 
e Enhanced method handling 

e Enhanced deprecation 


The new HTTP client [JEP-110] 


In this section, we will review Java's Hypertext Transfer Protocol (HTTP) client, starting 
with a pre-Java 9 look and then diving into the new HTTP client that is part of the Java 9 
platform. This approach is needed to support an understanding of the changes made in Java 
9. 


The HTTP client before Java 9 


JDK version 1.1 introduced the HttpURLConnection API that supported HTTP-specific 
features. This was a robust class that included the fields listed here: 


e chunkLength 
e fixedContentLength 

e fixedContentLengthLong 
e HTTP_ACCEPTED 
e HTTP_BAD_GATEWAY 

e HTTP_BAD_METHOD 

e HTTP_BAD_REQUEST 

e HTTP_CLIENT_TIMEOUT 

e HTTP_CONFLICT 

e HTTP_CREATED 

e HTTP_ENTITY_TOO_LARGE 
e HTTP_FORBIDDEN 

e HTTP_GONE 
e HTTP_INTERNAL_ ERROR 
e HTTP_LENGTH_REQUIRED 
e HTTP_MOVED_PER 
e HTTP_MOVED_TEMP 
e HTTP_MULT_CHOICE 
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e HTTP_NO_CONTENT 


e HTTP_NOT_ACCEPTABLE 


e HTTP_NOT_AUTHORITATIV. 


e HTTP_NOT_FOUND 


e HTTP_NOT_IMPLEMENTED 


e HTTP_NOT_MODIFIED 


e HTTP_OK 
e HTTP_PARTIAL 


T 


GI 


e HTTP_PAYMENT_REQUIRED 


e HTTP_PRECON_FATLED 
e HTTP_PROXY_AUTH 

e HTTP_REQ_ TOO_LONG 
e HTTP_RESET 

e HTTP_SEE_OTHER 

e HTTP_SERVER_ERROR 
e HTTP_UNAUTHORIZED 
e HTTP_UNAVAIABLE 

e HTTP_UNSUPPORTED_TYPE 
o HTTP_USE_PROXY 

e HTTP_VERSION 


e instanceFollowRedirects 


e method 


e responseCode 


e responseMessag 


As you can see from the list of fields, there was a great support for HTTP. In addition to a 
constructor, there are a plethora of available methods, including the following ones: 


e disconnect () 

èe getErrorStream () 

e getFollowRedirects () 

e getHeaderField(int n) 

e getHeaderFieldDate (String name, long Default) 
e getHeaderFieldKey (int n) 


e getInstanceFollowRedirects () 
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get 
get 


Permission () 


RequestMethod () 


ResponseCode () 


set 


set 


set 


set 


usi 


ResponseMessage () 

ChunkedStreamingMode (int chunklen) 
FixedLengthStreamingMode (int contentLength) 
FixedlengthStreamingMode (long contentLength) 
FollowRedirects (boolean set) 


InstanceFollowRedircts (boolean followRedirects) 


tRequestMethod (String method) 


ngProxy () 


The class methods listed earlier are in addition to the methods inherited from the 
java.net .URLConnection class and the java.lang.Object class. 


There were problems with the original HTTP client that made it ripe for updating with the 
new Java platform. Those problems were as follows: 


The 
incr 
The 


base URLConnect ion API had, defunct protocols such as Gopher and FTP 
easingly over the years 


HttpURLConnection API predated HTTP 1.1 and was overly abstract, 


making it less usable 


The 
and 


The 
The 


HTTP client was woefully under documented, making the API frustrating 
difficult to use 


client only functioned on one thread at a time 
API was extremely difficult to maintain due to the above points about it 


predating HTTP 1.1 and it lacking sufficient documentation 


Now that we know what was wrong with the HTTP client, let's look at what's in store for 


Java 9. 
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Java 9's new HTTP client 


There were several goals associated with creating the new HTTP client for the Java 9 
platform. JEP-110 was the organizing proposal for the new HTTP client. The primary goals 
of JEP-110 are listed here and featured the creation of the new HTTP client presented. These 
goals are presented in the broad categories of ease of use, core capabilities, additional 
capabilities, and performance: 


e Ease of use: 


The API was designed to provide up to 90 percent of HTTP-related 
application requirements. 


The new API is usable, without unnecessary complexity, for the 
most common use cases. 


A simplistic blocking mode is included. 


The API supports modern Java language features. Lambda 
expressions, a major new introduction released with Java 8, are an 
example. 


e Core capabilities: 
e Supports HTTPS/TLS 
e Supports HTTP/2 


e Provides visibility on all details related to HTTP protocol requests 
and responses 


e Supports standard/common authentication mechanisms 
e Provides headers received event notifications 
e Provides response body received event notifications 
e Provides error event notifications 
e Additional capabilities: 
e The new API can be used for WebSocket handshakes 
e It performs security checks in concert with the current networking 
API 


e Performance: 
e For HTTP/1.1: 
e The new API must perform at least as efficiently as 
the previous API. 
e Memory consumption must not exceed that of 
Apache HttpClient, Netty, and Jetty, when being 
used as a client API. 
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e For HTTP/2: 


e Performance must exceed that of HTTP/1.1. 

e The new performance must match or exceed that of 
Netty and Jetty when being used as a client API. No 
performance degradation should be a result of the 
new client. 

e Memory consumption must not exceed that of 
Apache HttpClient, Netty, and Jetty, when being 
used as a client API. 


e Avoids running timer threads 


New API limitations 


There are some intentional shortcomings of the new API. While this might sound counter- 
intuitive, the new API was not intended to completely replace the current 
HttpURLConnection API. Instead, the new API is intended to eventually replace the 


current one. 


The following code snippet provides an example of how to implement the 
HttpURLConnect class to open and read a URL in a Java application: 


/* 


import statements 


Af 


public class HttpUrlConnectionExample 


{ 


public static void main(String[] args) 


{ 


new HttpUrlConnectionExample () ; 


} 


public HttpUrlConnectionExample () 


{ 
U 


S 


/ 
S 


/ 


ct 


H 


RL theUrl = null; 


tringBuilder thes 


/ put the URL int 
tring theUrl = "h 


heUrl = new URL(t 
ttpURLConnection 


BufferedReader theReader = null; 


tringBuilder; 


o a String 
ttps://www.packtpub.com/"; 


/ here we are creating the connection 


heUrl); 
theConnection = (HttpURLConnection) 
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theUrl.openConnection(); 


theConnection.setRequestedMethod ("GET") ; 


/ add a delay 
heConnection.setReadTimeout (30000); // 30 seconds 
heConnection.connect (); 


PE TE ss 


// next, we can read the output 

theReader = new BufferedReader ( 

new InputStreamReader (theConnection.getInputStream())); 
heStringBuilder = new StringBuilder (); 


ct 


// read the output one line at a time 
String theLine = null; 
w 
{ 


hil ((theLine = theReader.readLine() != null) 


theStringBUilder.append(line + "\n"); 
} 


// echo the output to the screen console 
System.out.printin(theStringBuilder.toString()); 
// close the reader 

theReader.close(); 


The preceding code does not include exception handling for brevity. 


Here are some specific limitations of the new API: 


e Not all HTTP-related functionality is supported. It is estimated that about 10 
percent of the HTTP's protocol is not exposed by the API. 

e Standard/common authentication mechanisms have been limited to basic 
authentication. 

e The overarching goal of the new API was the simplicity of use, which means that 
performance improvements might not be realized. Certainly, there will be no 
performance degradation, but there is not likely to be an overwhelming level of 
improvement, either. 

e There is no support for filtering on requests. 
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e There is no support for filtering on responses. 
e The new API does not include a pluggable connection cache. 
e There is a lack of a general upgrade mechanism. 


The new API is delivered as part of the Java 9 platform in the incubator mode. This suggests 
that the API will be standardized in a future Java platform, perhaps with Java 10. 


Simplified Doclet API [JEP-221] 


The Doclet API and Javadoc are closely related. Javadoc is a documentation tool and the 
Doclet API provides functionality so that we can inspect the javadoc comments embedded 
at the source-levels of libraries and programs. In this section, we will review the pre-Java 9 
status of the Doclet API and then explore the changes introduced to the Doclet API in the 
Java 9 platform. In the following section, we will review Javadoc. 


The pre-Java 9 Doclet API 


The pre-Java 9 Doclet API, or the com. sun. javadoc package, gives us access to look at 
javadoc comments located in the source code. Invoking a Doclet is accomplished by using 
the start method. That method's signature is public static boolean start (RootDoc 
root). We will use the RootDoc instance as a container for the program structure 
information. 


In order to call javadoc, we need to pass the following: 


e Package names 
e Source file names (for classes and interfaces) 
e Anaccess control option--one of the following: 
e package 
e private 
e protected 
e public 


When the preceding listed items are used to call javadoc, a documented set is provided as a 
filtered list. If our aim is to obtain a comprehensive, unfiltered list, we can use 
allClasses (false). 
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Let's review an example Doclet: 


// Mandatory import statement. 
import com.sun.javadoc.*; 


// We will be looking for all the @throws documentation tags. 
public class AllThrowsTags extends Doclet 
{ 
// This is used to invoke the Doclet. 
public static boolean start (Rootdoc myRoot) 
{ 
// “ClassDoc[]" here referes to classes and interfaces. 
ClassDoc[] classesAndInterfaces = 
myRoot.classesAndInterfaces (); 
for (int i = 0; i < classesAndInterfaces.length; ++i) 
{ 
ClassDoc tempCD = classesAndInterfaces[i]; 
printThrows (tempCD.contructors())j; 
printThrows (tempCD.methods () ); 
} 


return true; 


static void printThrows (ExecutableMemberDoc[] theThrows) 
{ 
for (int i = 0; i < theThrows.length; ++i) 
{ 
ThrowsTag[] throws = theThrows[i].throwsTags(); 


// Print the "qualified name" which will be a the 
class or 

// interface name. 

System.out.printin(theThrows [i] .qualifiedName()) ; 


// A loop to print all comments with the Throws Tag that 
// belongs to the previously printed class or 
interface name 
for (int j = 0; j < throws.length; ++j) 
{ 
// A println statement that calls three methods 
from the 
// ThrowsTag Interface: exceptionType(), 
exceptionName(), 
// and exceptionComment (). 


System.out.printin("--> TYPE: " + 
throws[j].exceptionType() + 
" | NAME: " + throws[j].exceptionName() + 
" | COMMENT: " + throws[j].exceptionComment ()); 
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} 


As you can see by the thoroughly commented code, gaining access to the javadoc content is 
relatively easy. In our preceding example, we would invoke the All Throws class using the 
following code in the command line: 


javadoc -doclet AllThrowsTags -sourcepath <source-location> java.util 
The output of our result will consist of the following structure: 


<class or interface name> 
TYPE: <exception type> | NAME: <exception name> | COMMENT: <exception 


comment > 

TYPE: <exception type> | NAME: <exception name> | COMMENT: <exception 
comment > 

TYPE: <exception type> | NAME: <exception name> | COMMENT: <exception 
comment > 


<class or interface name> 
TYPE: <exception type> | NAME: <exception name> | COMMENT: <exception 


comment > 
TYPE: <exception type> | NAME: <exception name> | COMMENT: <exception 
comment > 
API enums 


The API consists of one enum, LanguageVersion, which provides the Java programming 
language version. The constants for this enum are Java_i_1 and Java_1_5. 


API classes 


The Doclet class provides an example of how to create a class to start a Doclet. It contains 
an empty Doclet () constructor and the following methods: 


e languageVersion () 


e optionLength (String option) 


start (RootDoc root) 


validOptions(String[][] options, DocErrorReporter reporter) 
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API interfaces 


The Doclet API contains the following listed interfaces. The interface names are self- 
describing. You can consult the documentation for additional details: 


e AnnotatedType 


e AnnotationDesc 


nnotationDesc.ElementValuePair 


nnotationTypeElementDoc 


A 
A 
A 

e AnnotationTypeDoc 
A 
AnnotationValue 
C 


n 
lassDoc 


e ConstructorDoc 


e DocErrorReporter 

e ExecutableMemberDoc 
e FieldDoc 

e MemberDoc 

e MethodDoc 

e PackageDoc 

e Parameter 

e ParameterizedType 


e ParamTag 


e ProgramElementDoc 


e RootDoc 

e SeeTag 

e SerialFieldTag 
e SourcePosition 
e Tag 

e ThrowsTag 

e Type 

e TypeVariable 

e WildcardType 
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Problems with the pre-existing Doclet API 


Fueling the need for a new Doclet API were several issues with the pre-existing Doclet API: 


e It was not ideal for testing or concurrent usage. This stemmed from its 
implementation of static methods. 


e The language model used in the API had several limitations and became more 
problematic with each successive Java upgrade. 


e The API was inefficient, largely due to its heavy use of substring matching. 


e There was no reference provided regarding the specific location of any given 
comment. This made diagnostics and troubleshooting difficult. 


Java 9's Doclet API 


Now that you have a good handle on the Doclet API as it existed prior to Java 9, let's look at 
what changes have been made and delivered with the Java 9 platform. The new Doclet API 
is in the jdk. javadoc. doclet package. 


At a high level, the changes to the Doclet API are as follows: 


e Updates the com. sun. javadoc Doclet API to take advantage of several Java SE 
and JDK APIs 


e Updates the com. sun.tools.doclets.standard.Standard Doclet to use the 
new API 


e Supports the updated Taglet API that is used to create custom javadoc tags 


In addition to the changes listed earlier, the new API uses the two APIs listed here: 


e Compiler tree API 
e Language model API 


Let's explore each of these in the following sections. 


Compiler tree API 


The compiler tree API is in the com. sun. source. doct ree package. It provides several 
interfaces to document source-level comments. These APIs are represented as Abstract 
Syntax Trees (ASTs). 


[254] 


www.EBooksWorld.ir 


New Tools and Tool Enhancements 


There are two enums: 


e AttributeTree.ValueKind with the following constants: 
e DOUBLE 


e EMPTY 
e SINGLE 
e UNQUOTED 


e DocTree. Kind with the following constants: 
e ATTRIBUTE 


e AUTHOR 
e CODE 


ERIAL 
RIAL_DATA 
(RIAL_FIELD 
e SINCE 
e START_ELEMENT 


(zal 


e 
wn 
T 
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The com. sun.source.doct ree package contains several interfaces. They are detailed in 


EXT 
HROWS 


e 
<¢ GqQHH 


ALUE 
ERSION 


° 
< 


NKNOWN_BLOCK_TAG 
NKNOWN_INLINE_TAG 


the following table: 
Interface name Extends A tree node for: Non-inherited methods 
AttributeTree DocTree HTML element getName (), getValue(), get ValueKind () 


AuthorTree 


BlockTagTree, 
DocTree 


@author block tag 


getName () 


BlockTagTree 


Comment Tree 


DeprecatedTree 


DocCommentTree 


DocTree 


BlockTagTree 


Base class for 
different types of 
block tags 


An embedded 
HTML comment 
with the following 
HTML tags--< ! -— 
text-—> 


@deprecated 
block tag 


Body block tags 


get TagName () 


getBody () 


getBody () 


getBlockTags (), getBody (), 
getFirstSentence() 


DocRootTree 


InlineTagTree 


@docroot inline 
tag 


N/A 


N/A 


Common interface 
for all 
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DocTreeVisitor<R, P> 


R=return type of 
visitor's methods; P 
= type of the 
additional 
parameter 


visitAttribute (AttributeTree node, P 
visitAuthor (AuthorTree node, P p), 
visitComment (CommentTree node, P p), 
visitDeprecated(DeprecatedTree node, 
visitDocComment (DocComment Tree 
visitDocRoot (DocRootTree node, 
visitEndElement (EndElementTree node, 
visitEntity(EntityTree node, P p), 
visitErroneous (ErroneousTree node, P 
visitIdentifier(IdentifierTree node, 
visitInheritDoc(InheritDocTree node, 
visitLink(LinkTree node, P p), 
visitLiteral (LiteralTree node, 
visitOther (DocTree node, P p), 
visitParam(ParamTree node, P p), 
visitReference (ReferenceTree node, P 
visitReturn(ReturnTree node, P p), 
visitSee(SeeTree node, P p), 
visitSerial(SerialTree node, P p), 
visitSerialData(SerialDataTree node, P p), 
visitSerialField(SerialFieldTree node, P 
p),visitSince(SinceTree node, P p), 
visitStartElement (StartElementTree node, P 
p), visitText (TextTree node, P p), 
visitThrows (ThrowsTree node, P p), 
visitUnknownBlockTag (UnknownBlockTagTree 
node, P p), 

visitUnknownInlineTag (UnknownInlineTagTree 
node, P p), visitValue (ValueTree node, P 
p), visitVersion(VersionTree node, P p) 


node, 
P p), 


P p), 


EndElementTree 


DocTree 


End of an HTML 
element </name> 


getName () 


EntityTree 


DocTree 


An HTML entity 


getName () 


ErroneousTree 


TextTree 


This is for 
malformed text 


getDiagnostic() 


dentifierTree 


DocTree 


An identifier in a 
comment 


getName () 


nheritDocTree 


nlineTagTree 


LinkTree 


InlineTagTree 


DocTree 


InlineTagTree 


@inheritDoc 
inline tag 
Common interface 


for inline tags 


@link or 
@linkplan inline 
tags 


N/A 


get TagName () 


getLabel (), getReference () 


LiteralTree 


ParamTree 


InlineTagTree 


BlockTagTree 


@literalor 
@code inline tags 


@param block tags 


getBody () 


getDescription(), getName (), 
isTypeParameter () 
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ReferenceTree 


DocTree 


Used to reference a 
Java lang element 


getSignature() 


ReturnTree 


BlockTagTree 


@return block tags 


getDescription() 


SeeTree 


SerialDataTree 


BlockTagTree 


BlockTagTree 


@see block tags 


@serialData 
block tags 


getReference () 


getDescription() 


SerialFieldTree 


BlockTagTree 


@serialData 
block tags and 
@serialField 
field names and 
descriptions 


getDescription(), getName (), get Type () 


SerialTree 


SinceTree 


BlockTagTree 


BlockTagTree 


@seria 


block tags 


@since block tags 


getDescription() 


getBody () 


StartElementTree 


TextTree 


DocTree 


DocTree 


Start of an HTML 
element < name 
[attributes] 
[/] > 


Plain text 


getAttributes (), getName(),isSelfClosing() 


getBody () 


ThrowsTree 


UnknownBlockTagTree 


BlockTagTree 


BlockTagTree 


@exceptionor 
@throws block tags 


Unrecognized 
inline tags 


getDescription(), getExceptionname () 


getContent () 


UnknownInlineTagTree 


InlineTagTree 


Unrecognized 
inline tags 


getContent () 


ValueTree 


InlineTagTree 


@value inline tags 


getReference () 


VersionTree 


Language model API 


BlockTagTree 


@version block 
tags 


getBody () 


The language model API is in the java. lang.model package. It includes packages and 
classes that are used for language processing and language modeling. It consists of the 
following components: 


e AnnotatedCons 


e SourceVersion 


e Unknown 


enum. 


truct interface 


Ent ityException exception 


Each of these language model API components is further explored in the next three sections. 
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The AnnotatedConstruct interface 


The AnnotatedConstruction interface provides an annotatable construct to the language 
model API that has been part of the Java platform since version 1.8. It is applicable to 
constructs that are either an element (Interface Element) or a type (Interface TypeMirror). 
The annotations for each of these constructs differ, as shown in this table: 


TypeMirror | Based on use of a type name 


The AnnotatedConstruction interface has three methods: 


e getAnnotation(Class<A> annotationType): This method returns the type 
of the construct's annotation 


e getAnnotationMirrors (): This method returns a list of annotations that are on 
the construct 


e getAnnotationsByType(Class<A> annotationType): This method returns 
the construct's associated annotations 


The SourceVersion enum 


The SourceVersion enum consists of the following constants: 


zj 
miri 
kal 
D 
Wn 

zj 


7 
miri 
kal 
D 
wn 

zj 


7 
miri 
kal 
D 
wn 

zj 


7 
miri 
kal 
D 
Wn 

zj 


Ei 
4 
Lt] 
> 
n 
ool ee | 
ONY Dn oO BF WY FP OC 


Tj 
4 
ea 
D 
Nn 

Tj 


7 
miri 
al 
D 
wn 

zj 


* 
a 
i 
4 
° RELEASE 
= 
Ri 
Ri 
i 


ELEASE 


T 
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It is anticipated that the SourceVersion enum will be updated to include 
RELEASE_9 once the Java 9 platform has been officially released. 


This enum also contains several methods, which are as follows: 

Method name: isIdentifier 

public static boolean isIdentifier(CharSequence name) 

This method returns t rue if the parameter string is a Java identifier or keyword. 
Method name: isKeyword 

public static boolean isKeyword(CharSequence s) 

This method returns true if the given CharSequence is a literal or keyword. 
Method name: isName 

public static boolean isName (CharSequence name) 

This method returns t rue if the CharSequence is a valid name. 

Method name: latest 

public static SourceVersion latest () 

This method returns the latest source version for modeling purposes. 

Method name: latest Supported 

public static SourceVersion latestSupported () 

This method returns the latest source version that can be fully supported for modeling. 
Method name: valueOf 


public static SourceVersion valueOf (String name) 


[ 260 ] 


www.EBooksWorld.ir 


New Tools and Tool Enhancements 


This method returns the enum constant based on the parameter string provided. 


You should be aware that the value (String name) method throws two 
exceptions: IllegalArgumentException and NullPointerException. 


Method name: values 
public static SourceVersion[] values () 


This method returns an array of the enum constants. 


The UnknownEntityException exception 


The UnknownEnt it yException class extends Runt imeException and is a superclass of 
unknown exceptions. The class constructor is as follows: 


protected UnknownEntityException (String message) 


The constructor creates a new instance of UnknownEnt ityException with the message 
provided as a string argument. The method does not take additional arguments. 


This class does not have its own methods, but inherits methods from both 
java.lang.Throwable and class.java.lang.Object classes as shown here: 


The java.lang. Throwable class methods: 


e addSuppressed() 

e fillInStackTrace() 

e getCause () 

e getLocalizedMessage () 
e getMessage() 

e getStackTrace() 

e getSuppressed() 

e initCause() 

e printStackTrace() 

e setStackTrace() 


e toString () 
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The java.lang.Object class methods: 


e clone () 

è equals () 

e finalize() 
e getClass () 
e hashCode () 


notify () 
notifyAll () 


e wait () 


HTML5 Javadoc [JEP-224] 


The Javadoc tool has been updated for the Java 9 platform. It can now generate HTML 5 
markup output in addition to HTML 4. The new Javadoc tool provides support for both 


HTML 4 and HTML 5. 


HTML 4 will continue, even with the advent of the Java 9 platform, to be the default 
Javadoc output format. HTML 5 will be an option and will not become the default output 


markup format until Java 10. 


The following short Java application simply generates a 31 9-wide by 319-high frame. It is 
shown here without any Javadoc tags, which we will discuss later in this section: 


/import javax.swing.JFrame; 
import javax.swing.WindowConstants; 


public class Javadocl 


{ 


public static void 


{ 


drawJFrame(); 


} 


public static void 


{ 


JFrame myFrame = 


Example 


main(String[] args) 


drawJFrame () 


new JFrame("Javadoc Example"); 


myFrame.setSize (319,319); 

myFrame.setDefaultCloseOperation ( 
WindowConstants.EXIT_ON_CLOSE) ; 

myFrame.setVisible (true); 
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} 


Once your package or class is completed, you can generate a Javadoc using the Javadoc tool. 
You can run the Javadoc tool, located in your JDK /bin directory, from the command line or 
from within your Integrated Development Environment (IDE). Each IDE handles Javadoc 
generation differently. For example, in Eclipse, you would select Project from the pull- 
down menu and then Generate Javadoc. In the IntelliJ IDEA IDE, you select the Tools pull- 
down menu and then Generate Javadoc. 


The following screenshot shows the IntelliJ IDEA interface for the Generate Javadoc 
functionality. As you can see, the -htm15 command-line argument has been included: 


Specify Generate JavaDoc Scope 


Generate JavaDoc scope 
O Whole project 
@ File '[Chapter11] - ...\src\JavadocExample.java’ 


© Custom scope 
Include test sources 
(J Include JDK and library sources in -sourcepath 
K documentation (use -link optior 
Output directory: C:A\Chapter11\JD-Output 


private Generate hierarchy tree @use 
Generate navigation bar @author 
Generate index @version 
pea Separate index per letter | [_] @deprecated 


package 
public deprecated list 
Locale: 

Other command line arguments: | -html5 

Maximum heap size (Mb): 


Open generated documentation in browser 


(23 Cancel 
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When the OK button is clicked, you will see a series of status messages, as shown in the 
following example: 


"C:\Program Files\Java\jdk-9\bin\javadoc.exe" -public -splitindex -use - 
author -version -nodeprecated —htm15 

ac: \Users\elavi\AppData\Local\Temp\javadoc1304args.txt -d C:\Chapter11\JD- 
Output 

Loading source file C:\Chapter11\src\JavadocExample.java... 

Constructing Javadoc information... 

Standard Doclet version 9 

Building tree for all the packages and classes... 

Generating C:\Chapter11\JD-Output\JavadocExample.html... 


Generating C:\Chapter11\JD-Output\package-frame.html... 

Generating C:\Chapter11\JD-Output\package-summary html... 
Generating C:\Chapter11\JD-Output\package-tree.html... 

Generating C:\Chapter11\JD-Output\constant-values.html... 
Generating C:\Chapter11\JD-Output\class-—use\JavadocExample.html... 


Generating C:\Chapter11\JD-Output\package-use.html... 
Building index for all the packages and classes... 

Generating C:\Chapter11\JD-Output\overview-tree.html... 
Generating C:\Chapter11\JD-Output\index—files\index-1.html... 
Generating C:\Chapter11\JD-Output\index—files\index-2.html... 
Generating C:\Chapter11\JD-—Output\index—files\index-3.html... 
Building index for all classes... 

Generating C:\Chapter11\JD-Output\allclasses—frame.html... 
Generating C:\Chapter11\JD-Output\allclasses—frame.html... 
Generating C:\Chapter11\JD-Output\allclasses-noframe.html... 
Generating C:\Chapter11\JD-Output\allclasses—noframe.html... 
Generating C:\Chapter11\JD-Output\index.html... 

Generating C:\Chapter11\JD-Output\help-doc.html... 


javadoc exited with exit code 0 


Once the Javadoc tool exits, you are ready to view the Javadoc. Here is a screenshot of what 
was generated based on the previously provided code. As you can see, it is formatted in the 
same manner in which the formal Java documentation from Oracle is documented: 
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USE TREE INDEX HELP 


PREV CLASS NEXTCLASS FRAMES NOFRAMES ALL CLASSES SEARCH: | Search| 
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD 
Class JavadocExample 


java.lang.Object 
JavadocExample 


public class JavadocExample 
extends java.lang.Object 


JavadocExample() 


Method Summary 


| | static Methods | Concrete Methods 
Modifier and Type Method 
static void drawJFrame() 


static void main(java.lang.String[{] args) 


Methods inherited from class java.lang.Object 


equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait 


JavadocExample 


public JavadocExample() 


drawJFrame 


public static void drawJFrame() 


main 


public static void main(java.lang.String[] args) 


PACKAGE USE TREE INDEX HELP 


PREV CLASS NEXT CLASS FRAMES NOFRAMES ALL CLASSES 
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD 
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When we generated the Javadoc, multiple documents were created, as illustrated by the 
directory tree provided in the following screenshot: 


è allclasses-frame.html 

è allclasses-noframe.html 

MM class-use 

@ constant-values.html 

è help-doc.html 

P index-files 

è index.html 

è JavadocExample.html 

MS jquery 

®) member-search-index.js 
member-search-index.zip 
overview-tree.html 
package-frame.html 
package-list 
package-summary.html 
package-tree.html 
package-use.html 
resources 
script.js 
search.js 
stylesheet.css 
type-search-index.js 
type-search-index.zip 


You can also add optional tags that are recognized by the Javadoc tool. Those tags are 
provided here: 


e @author 

e @code 

e @deprecated 
e @docRoot 

e @exception 
e @inheritDoc 
e @link 
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@linkplain 
@param 
@return 

@see 

@serial 
@serialData 
@serialField 
@since 
@throws 


@value 


@version 


For more information on how to write document comments for the 
Javadoc tool, you can visit Oracle's official instructions at http://www. 


oracle.com/technetwork/articles/java/index-137868.html. 


Javadoc search [JEP-225] 


Prior to Java 9, the standard Doclet generated API documentation pages that made 
navigating them difficult. Unless you are very familiar with the layout of these 
documentation pages, you will likely use browser-based find functionality to search text. 
This is considered clunky and suboptimal. 


The Java 9 platform includes a search box as part of the API documentation. This search box 
is granted by the standard Doclet and can be used to search for text within the 
documentation. This represents a great convenience for developers and is likely to change 
our usage of Doclet-generated documentation. 


With the new Javadoc search functionality, we have the ability to search for the following 
indexed components: 


Module names 
Package names 


Types 
Members 


Terms/phrases indexed using the new @ index inline tag 
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Introducing camel case search 


The new Javadoc search functionality includes a great shortcut using camel case search. As 
an example, we can search for openED to find the openExternalDatabase() method. 


Remove launch-time JRE version selection 
[JEP-231] 


Prior to Java 9, we could use the mJRE (Multiple JRE) feature to specify a specific JRE 
version, or range of versions, for launching our applications. We would accomplish this via 
the command-line option -version or with an entry in the JAR file's manifest. The 
following flowchart illustrates what happens based on our selection: 


Request JRE 
version 
(or range) 


Does 
launched Launcher searches 


JRE meet for appropriate 


request version 
? 


Is 


[launch | beri 
Launch version 


available? 


This functionality was introduced with JDK 5 and was not fully documented in that release 
or any subsequent release prior to JDK 9. 
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The following specific changes were introduced with the Java 9 platform: 


e The mJRE feature has been removed. 

e The launcher will now produce an error whenever the -version command-line 
option is used. This is a terminal errors in that processing will not continue. 

e A warning will be produced if there is a -version entry ina JARs manifest. The 
warning will not stop execution. 


Interestingly, the presence of a -version entry in a manifest file will only generate a 
warning. This is by design, to take into account the likelihood of the entry being in older 
JAR file. It is estimated that this warning will be changed into a terminal error when the 
Java 10 platform is released. 


Parser API for Nashorn [JEP-236] 


The focus of JEP 236 was to create an API for Nashorn's EMCAScript abstract syntax tree. In 
this section, we will individually look at Nashorn, EMCAScript and then the Parser API. 


Nashorn 


Oracle Nashorn is a JavaScript engine for the JVM developed in Java by Oracle. It was 
released with Java 8. It was created to provide developers with a highly efficiently and 
lightweight JavaScript runtime engine. Using this engine, developers were able to embed 
JavaScript code in their Java applications. Prior to Java 8, developers had access to the 
JavaScript engine created by Netscape. That engine, introduced in 1997, was maintained by 
Mozilla. 


Nashorn can be used both as a command-line tool and as an embedded interpreter in Java 
applications. Let's look at examples of both. 


Rhino-named JavaScript engine from the Mozilla Foundation. Rhino is 
said to have originated from the picture of the animal on a JavaScript book 


@ Nashorn is the German word for rhinoceros. The name spawned from the 
cover. File this one under interesting facts. 


[ 269 ] 


www.EBooksWorld.ir 


New Tools and Tool Enhancements 


Using Nashorn as a command-line tool 


The Nashorn executable file, jjs . exe, resides in the \bin folder. To access it, you can 
navigate to that folder or, if your system path is set up appropriately, you can launch into 
the shell by entering the jjs command in a Terminal / Command Prompt window on your 


system: 


1) bin 
COPYRIGHT 
BB db 
B include 
b javafx-sre.zip 
B jre 
© lib 
LICENSE 
B man 
è README.html 
release 
P sre.zip 


THIRDPARTYLICENSEREADME-JAVAFX.txt 


THIRDPARTYLICENSEREADME.txt 


E appletviewer 
H extcheck 
E idl 

H jar 

E jarsigner 
H java 

H javac 

H javadoc 

W javafxpackager 
H javah 

H javap 

MB javapackager 
H jcmd 

H jconsole 
BB jdb 

H jdeps 

BB jhat 

E jinto 

H jjs 

E jmap 

H jmc 

E jps 

E jrunscript 
H jsadebugd 
H jstack 

H jstat 

H jstatd 

E jvisualvm 
BB keytool 

H native2ascii 
E orbd 

W pack200 
E policytool 
E mic 

E mid 

E rmiregistry 
MB schemagen 
H serialver 
E servertool 
E tnameserv 
MB unpack200 
E wsgen 

E wsimport 


H xjc 


jis 


3 3/15/17, 3:54 AM 


3/15/17, 3:54 AM 
3/15/17, 3:54 AM 
Add Tags... 
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Here, you can see an open terminal window that first checks the version of Java and then 

uses the jjs -version command to launch the Nashorn shell. In this example, both Java 
and Nashorn are version 1.8.0.121. Alternatively, we can simply launch Nashorn with the 
jjs command, and the shell will open without the version identification: 


Edwards—-iMac:~ edljr$ java -version 
java version "1.8.0_121" 


Java(TM) SE Runtime Environment (build 1.8.@_121-b13) 

Java HotSpot(T) 64-Bit Server VM (build 25.121-b13, mixed mode) 
Edwards—iMac:~ edljr$ jjs -version 

nashorn 1.8.0_121 

jis> 


Next, let's create a short JavaScript and run it using Nashorn. Consider the following simple 
JavaScript code that has three simple lines of output. 


var addtest = function() 
{ 
print ("Simple Test"); 
print ("This JavaScript program adds the numbers 300 


and 19."); 
print ("Addition results = " + (300 + 19)); 
} 
addtest (); 


To have Java run this JavaScript application, we will use the jjs address.js command. 
Here is the output: 


(E) @ edljr — -bash — 71x7 


Edwards-iMac:~ edljr$ jjs addtest.js 


Simple Test 

This JavaScript program adds the numbers 300 and 19. 
Addition results = 319 

Edwards-iMac:~ edljr$ F 
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There is a lot you can do with Nashorn. From the Command Prompt/Terminal window, we 
can execute jjs with the -help option to see a full list of command-line commands: 


(ER) A edijr — -bash — 105x47 


Edwards-iMac:~ edljr$ jjs -help 
jjs [<options>] <files> [-- <arguments>] 
-D (-Dname=value. Set a system property. This option can be repeated.) 


-cp, -classpath (-cp path. Specify where to find user class files.) 


-doe, -dump-on-error (Dump a stack trace on errors.) 
param: [true| false] default: false 


-fv, -fullversion (Print full version info of Nashorn.) 
param: [true| false] default: false 


-fx (Launch script as an fx application.) 
param: [true|false] default: false 


-h, -help (Print help for command line flags.) 
param: [true|false] default: false 


--language (Specify ECMAScript language version.) 
param: [es5|es6] default: es5 


-ot, --optimistic-types (Use optimistic type assumptions with deoptimizing recompilation. 
This makes the compiler try, for any program symbol whose type cannot 
be proven at compile time, to type it as narrow and primitive as 
possible. If the runtime encounters an error because symbol type 
is too narrow, a wider method will be generated until steady stage 
is reached. While this produces as optimal Java Bytecode as possible, 
erroneous type guesses will lead to longer warmup. Optimistic typing 
is currently disabled by default, but can be enabled for significantly 
better peak performance. ) 

param: [true| false] default: false 


-scripting (Enable scripting features.) 
param: [true| false] default: false 


-strict (Run scripts in strict mode.) 
param: [true|false] default: false 


-t, -timezone (Set timezone for script execution.) 
param: <timezone> default: America/Chicago 


-v, -version (Print version info of Nashorn.) 
param: [true|false] default: false 


Edwards-iMac:~ edljr$ I 


As you can see, using the -scripting option gives us the ability to create scripts using 
Nashorn as a text editor. There are several built-in functions that are useful when using 
Nashorn: 


e echo (): This is similar to a System. out.print () Java method 
e exit (): This exits Nashorn 
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e load(): This loads a script from a given path or URL 
e print (): This is similar to a System. out.print () Java method 
e readFull (): This reads a file's contents 


e readLine (): This reads a single line from stdin 
e quit (): This exits Nashorn 


Using Nashorn as an embedded interpreter 


A more common use of Nashorn, compared to using it as a command-line tool, is using it as 
an embedded interpreter. The javax.script API is public and can be accessed via the 
nashorn identifier. The following code demonstrates how we can gain access to Nashorn, 
define a JavaScript function, and obtain the results--all from within a Java application: 


// required imports 
import javax.script.ScriptEngine; 
import javax.script.ScriptEngineManager; 


public class EmbeddedAddTest 
{ 


public static void main(String[] args) throws Throwable 


{ 


// instantiate a new ScriptEngineManager 
ScriptEngineManager myEngineManager = 
new ScriptEngineManager (); 


// instantiate a new Nashorn ScriptEngine 
ScriptEngine myEngine = myEngineManager.getEngineByName ( 
"nashorn"); 


// create the JavaScript function 
myEngine.eval ("function addTest (x, y) { return x + y; }"); 


// generate output including a call to the addTest function 
via the engine 
System.out.println("The addition results are: 
" + myEngine.eval ("addTest (300, 19);")); 
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Here is the output provided in the console window: 


eclarat Æ Console $3 


<terminated> EmbeddedAddTest [Java Application) /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java (Aug 8, 2017, 1:44:24 PM 
The addition results are: 319.0 


This is a simplistic example to give you an idea of what is possible with embedded use of 
Nashorn. There are ample examples in Oracle's official documentation. 


EMCAScript 


EMCA (European Computer Manufacturers Association) was formed in 1961 as a 
standards organization for both information systems and communications systems. Today, 
the EMCA continues to develop standards and issue technical reports to help standardize 
how consumer electronics, information systems, and communications technology are used. 
They are over 400 ECMA standards, most of which have been adopted. 


You will notice that EMCA is not spelled with all capital letters as it is no 
longer considered an acronym. In 1994, the European Computer 
Manufacturers Association formally changed its name to EMCA. 


EMCAScript, also referred to as ES, was created in 1997 as a scripted-language specification. 
JavaScript implements this specification. The specification includes the following: 


e Complementary technologies 
e Libraries 

e Scripting language syntax 

e Semantics 
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Parser API 


One of the changes in the Java platform with version 9 is to provide specific support for 
Nashorn's EMCAScript abstract syntax tree. The goals of the new API are to provide the 
following: 


Interfaces to represent Nashorn syntax tree nodes 


The ability to create parser instances that can be configured with command-line 
options 


A visitor pattern API for interfacing with AST nodes 


Test programs to use the API 


The new API, jdk.nashorn.api.tree, was created to permit future changes to the 
Nashorn classes. Prior to the new Parser API, IDEs used Nashorn's internal AST 
representations for code analysis. According to Oracle, use of the 
idk.nashorn.internal.ir package prevented the modernization of Nashorn's internal 
classes. 


Here is a look at the the class hierarchy of the new jdk.nashorn.api.tree package: 


Class Hierarchy 


o java.lang.Object 
o jdk.nashorn.api.tree.SimpleTreeVisitorES5 1<R,P> (implements jdk.nashorn.api.tree. TreeVisitor<R,P>) 
o jdk.nashorn.api.tree.SimpleTreeVisitorES6<R,P> 
ə java.lang. Throwable (implements java.io.Serializable) 
o java.lang.Exception 
o java.lang.RuntimeException 
o jdk.nashorn.api.tree. UnknownTreeException 
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The following graphic illustrates the complexity of the new API, featuring a full interface 
hierarchy: 


Interface Hierarchy 


o jdk.nashorn.api.tree.Diagnostic 
o jdk.nashorn.api.tree.DiagnosticListener 
o jdk.nashorn.api.tree.LineMap 
o jdk.nashorn.api.tree.Parser 
o jdk.nashorn.api.tree. Tree 
o jdk.nashorn.api.tree.CaseTree 
o jdk.nashorn.api.tree.CatchTree 
o jdk.nashorn.api.tree.CompilationUnitTree 
o jdk.nashorn.api.tree.ExportEntryTree 
o jdk.nashorn.api.tree.ExpressionTree 
jdk.nashorn.api.tree.ArrayAccessTree 
jdk.nashorn.api.tree.ArrayLiteralTree 
jdk.nashorn.api.tree.AssignmenttTree 
jdk.nashorn.api.tree.BinaryTree 
jdk.nashorn.api.tree.ClassExpressionTree 
jdk.nashorn.api.tree.CompoundAssignmenttTree 
jdk.nashorn.api.tree.ConditionalExpressionTree 
jdk.nashorn.api.tree.ErroneousTree 
jdk.nashorn.api.tree.FunctionCallTree 
jdk.nashorn.api.tree.FunctionExpressionTree 
jdk.nashorn.api.tree.IdentifierTree 
jdk.nashorn.api.tree.InstanceOfTree 
jdk.nashorn.api.tree.LiteralTree 
jdk.nashorn.api.tree. MemberSelectTree 
jdk.nashorn.api.tree.NewTree 
jdk.nashorn.api.tree.ObjectLiteralTree 
jdk.nashorn.api.tree.ParenthesizedTree 
jdk.nashorn.api.tree.RegExpLiteralTree 
jdk.nashorn.api.tree.SpreadTree 
jdk.nashorn.api.tree. femplateLiteralTree 
jdk.nashorn.api.tree.UnaryTree 
o jdk.nashorn.api.tree. YieldTree 
jdk.nashorn.api.tree.ImportEntryTree 
jdk.nashorn.api.tree.ModuleTree 
jdk.nashorn.api.tree.PropertyTree 
jdk.nashorn.api.tree.StatementTree 
jdk.nashorn.api.tree.BlockTree 
jdk.nashorn.api.tree.ClassDeclarationTree 
jdk.nashorn.api.tree.DebuggerTree 
jdk.nashorn.api.tree.EmptyStatementTree 
jdk.nashorn.api.tree.ExpressionStatementTree 
jdk.nashorn.api.tree.FunctionDeclarationTree 
jdk.nashorn.api.tree.GotoTree 
o jdk.nashorn.api.tree.BreakTree 
o jdk.nashorn.api.tree.ContinueTree 
jdk.nashorn.api.tree.IfTree 
jdk.nashorn.api.tree.LabeledStatementTree 
o jdk.nashorn.api.tree.LoopTree 
o jdk.nashorn.api.tree.ConditionalLoopTree 
o jdk.nashorn.api.tree.DoWhileLoopTree 
o jdk.nashorn.api.tree.ForLoopTree 
o jdk.nashorn.api.tree.WhileLoopTree 
o jdk.nashorn.api.tree.ForinLoopTree 
o jdk.nashorn.api.tree.ForOfLoopTree 
jdk.nashorn.api.tree.ReturnTree 
jdk.nashorn.api.tree.SwitchTree 
jdk.nashorn.api.tree. ThrowTree 
jdk.nashorn.api.tree. TryTree 
jdk.nashorn.api.tree. VariableTree 
jdk.nashorn.api.tree.WithTree 
o jdk.nashorn.api.tree. TreeVisitor<R,P> 
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The last component of the jdk.nashorn.api.tree package is the enum hierarchy, shown 
here: 


Enum Hierarchy 


o java.lang.Object 
o java.lang.Enum<E> (implements java.lang.Comparable<T>, java.io.Serializable) 
o jdk.nashorn.api.tree. Diagnostic.Kind 
o jdk.nashorn.api.tree. Tree.Kind 


Multi-release JAR files [JEP-238] 


The JAR file format has been extended in the Java 9 platform and now permits multiple 
versions of class files to exist in a single JAR file. The class versions can be specific to a Java 
release version. This enhancement allows developers to use a single JAR file to house 
multiple releases of their software. 


The JAR file enhancement includes the following: 


e Support for the JarFile API 
e Support for standard class loaders 


The changes to the JAR file format resulted in necessary changes to core Java tools so that 
they are able to interpret the new multiple-release JAR files. These core tools include the 
following: 


e javac 
e javap 
e jdeps 
Finally, the new JAR file format supports modularity as the key characteristic of the Java 9 


platform. The changes to the JAR file format have not resulted in reduced performance of 
related tools or processes. 


Identifying multi-release JAR files 


Multi-release JAR files will have a new attribute, Multi-Release: true. This attribute 
will be located in the JAR MANIFEST .MF main section. 
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The directory structure will differ between standard JAR files and multi-release JAR files. 
Here is a look at a typical JAR file structure: 


jar root 
Apple.class 
Banana.class 
Coconut.class 
Dragonfruit.class 
Elderberry.class 


This illustration shows the new multi-release JAR file structure with Java version-specific 
class files for both Java 8 and Java 9: 


jar root 
Apple.class 
Banana.class 
Coconut.class 
Dragonfruit.class 
Elderberry.class 
META-INF 
versions 
8 
Apple.class 
Banana.class 
Coconut.class 
Dragonfruit.class 
Elderberry.class 


Apple.class 
Banana.class 
Coconut.class 
Dragonfruit.class 
Elderberry.class 
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Related JDK changes 


Several changes had to be made to the JDK to support the new multi-release JAR file 
format. These changes include the following: 


The URLClassLoader is JAR-based and was modified so that it can read class 
files from the specified version. 

The new module-based class loader, new to Java 9, was written so that it can read 
class files from the specified version. 

The java.util.jar.JarFile class was modified so that it selects the 
appropriate class version from the multi-release JAR files. 

The JAR URL scheme's protocol handler was modified so that it selects the 
appropriate class version from the multi-release JAR files. 

The Java Compiler, javac, was made to read identified versions of the class files. 
These version identifications are made using the -target and -releas 
command-line options with the JavacFileManager API and the 
ZipFileSystem API. 


The following tools were modified to take advantage of the changes to the 
JavacFileManager API and the ZipFileSystem API: 
e javah: This generates C header and source files 
e schemagen: This is the schema generator for namespaces in Java 
classes 
e wsgen: This is the parser for web service deployment 


The javap tool was updated to support the new versioning schema. 

The jdeps tool was modified to support the new versioning schema. 

The JAR packing tool set was updated accordingly. This tool set consists of 
pack200 and unpack200. 


Of course, the JAR tool was enhanced so that it can create the multi-release JAR 
files. 


All related documentation has been updated to support all the changes involved in 
establishing and supporting the new multi-release JAR file format. 
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Java-level JVM compiler interface [JEP-243] 


The JEP-243 was to create a Java-based JVM Compiler Interface (()VMCI). The JVMCI 
enables a Java compiler (which must have been written in Java) to be used as a dynamic 
compiler by the JVM. 


The reasoning behind the desire for the JVMCI is that it would be a highly optimized 
compiler that does not require low-level language features. Some JVM subsystems require 
low-level functionality, such as with garbage collection and bytemode interpretation. So, 
the JVMCI was written in Java instead of C or C++. This provides the collateral benefit of 
some of Java's greatest features, such as the following ones: 


e Exception handling 

e IDEs that are both free and robust 
e Memory management 

e Runtime extensibility 

e Synchronization 

e Unit testing support 


As JVMCI was written in Java, it will arguably be easier to maintain. 
There are three primary components of the JVMCI API: 


e Virtual machine data structure access 
e Installing compiled code with its metadata 
e Using the JVM's compilation system 


The JVMCI actually existed, to some extent, in Java 8. The JVMCI API was only accessible 
via a class loader that worked for code on the boot class path. In Java 9, this changes. It will 
still be experimental in Java 9, but more accessible. In order to enable the JVMCI, the 
following series of command-line options must be used: 


-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler - 
Djvmci.Compiler=<name of compiler> 


Oracle is keeping the JVMCI experimental in Java 9 to permit further testing and to afford 
the greatest level of protection for developers. 
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BeanInfo annotations [JEP-256] 


The JEP-256 focused on replacing @beani fo javadoc tags with more appropriate 
annotations. Furthermore, these new annotations are now processed at runtime so that 
BeanInfo classes can be generated dynamically. The modularity of Java 9 resulted in this 
change. The creation of custom BeanInfo classes has been simplified and the client library 
has been modularized. 


In order to fully grasp this change, we will review JavaBean, BeanProperty, and 
SwingContainer before going any further into this JEP. 


JavaBean 


A JavaBean is a Java class. Like other Java classes, JavaBeans are reusable code. They are 
unique in their design because they encapsulate several objects into one. There are three 
conventions a JavaBean class must follow: 


e The constructor should not take any arguments 
e It must be serializable 
e It must contain mutator and accessor methods for its properties 


Here is an example JavaBean class: 


public class MyBean implements java.io.Serializable 
{ 

// instance variables 

private int studentId; 

private String studentName; 


// no-argument constructor 
public MyBean () 
{ 
} 
// mutator/setter 
public void setStudentId(int thelID) 
{ 
this.studentId = thelID; 
} 


// accessor/getter 
public int getStudentId() 
{ 


return studentId; 
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} 


} 


// mutator/setter 
public void setStudentName (String theName) 
{ 
this.studentName = theName; 
} 


// accessor/getter 
public String getStudentName () 


{ 


return studentName; 


} 


Accessing JavaBean Classes is as simple as using the mutator and accessor methods. This is 
likely not new to you, but there is a good chance you did not know that those carefully 
coded classes you created were called JavaBean classes. 


BeanProperty 


BeanProperty is an annotation type. We use this annotation to specify a property so that 
we can automatically generate BeanInfo classes. This is a new annotation for Java 9. 


The BeanProperty annotation has the following optional elements: 


boolean bound 

String description 
String[] enumerationValues 
boolean expert 

boolean hidden 

boolean preferred 

boolean required 


boolean visualUpdate 
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SwingContainer 


SwingContainer is an annotation type. We use this annotation to specify a swing-related 
property so that we can automatically generate BeanInfo classes. This is anew annotation 
for Java 9. 


The SwingContainer annotation has the following optional elements: 


e String delegate 


e boolean value 


Now that we have reviewed JavaBean, BeanProperty, and SwingContainer, let's take a 
look at the BeanInfo classes. 


Beanlnfo classes 


For the most part, BeanInfo classes are automatically generated at runtime. The exception 
is with Swing classes. Those classes generate BeanInfo classes based on the @beaninfo 
javadoc tags. This is done at compile time, not runtime. In Java 9, the @beaninfo tags have 
been replaced with @interface JavaBean, @interface BeanProperty, and 
@interface SwingContainer annotations. 


These new annotations are used to set the corresponding attributes based on the optional 
elements noted in the previous sections. As an example, the following code snippet sets the 
attributes for a SwingContainer: 


package javax.swing; 


public @interface SwingContainer 
{ 
boolean value() default false; 
String delegate() default ""; 
} 


This provides us with three benefits: 


e It will be much easier to specify attributes in Bean classes instead of having to 
create individual BeanInfo classes 


e We will be able to remove auto-generated classes 
e The client library is much more easily modularized with this approach 
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TIFF image input/output [JEP-262] 


JEP-262 is pretty straight forward. For Java 9, the image input/output plugins have been 
extended to include support for the TIFF image format. The ImageI0 class extends the 
Object class and is part of Java SE. The class contains several methods for encoding and 
decoding images. Here is a list of static methods: 


createImageOutputStream(Object output) 
CacheDirectory 

getImageReader (ImageWriter writer) 

Iterator of current ImageReader 


s 
getImageReadersByFormatName (String Iterator of current ImageReaders 


formatName) with the specified format name 


ReadersByMIMEType (String MIMI Iterator of current ImageReader 
of the specified MIME type 


mageReadersBySuffix(String fileSuffix) |Iterator of current ImageReader 
with the specified suffix. 


mageTranscoders (ImageReader reader) Iterator of current 
ImageTranscoders 


mageWriter (ImageReader reader) ImageWriter 


mageWriters (ImageTypeSpecifier type, Iterator of current ImageWriters 
ng formatName) that can encode to the specified 
type 


getImageWritersByFormatName (String Iterator of current ImageWriters 
formatName) with the specified format name 
ritersByMIMEType (String MIMI Iterator of current ImageWriters 
of the specified MIME type 
getImageWritersBySuffix(String fileSuffix) | Iterator of current ImageWriters 
with the specified suffix. 
getReaderFileSuffixes () String array with file suffixes 
understood by current readers 
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getReaderFormatNames String array with format names 
understood by current readers 
getReaderMIMETypes String array with MIME types 
understood by current readers 
getUseCache () UseCache value 
get j i 
et 


0) 
E 0 
WriterFileSuffixes () String array of file suffixes 
understood by current writers 
0) 
F 0 
) 


getWriterFormatNames String array with format names 
understood by current writers 

getWriterMIMETypes String array with MIME types 
understood by current writers 

read(File input BufferedImage with an 
ImageReader 


( 
read(ImageInputStream stream) BufferedImage with 


ImageInput Stream and an 
ImageReader 


read(InputStream input) BufferedImage with 
InputStream and ImageReader 

read(URL input) BufferedImage with an 
ImageReader 


There are also a few static methods that do not return a value or return a Boolean: 


scanForPlugins () Performs the following actions: 
e Scans the application classpath for plugins 
e Loads plugin service provider classes 
e Registers service provide instances in the 
HORegistry 


setCacheDirectory (File This is where the cache files will be stored. 
cacheDirectory) 


setUseCache (boolean useCache) This method toggles if the cache will be 
disk-based or not. This applies to 
ImageInputStream and 
ImageOutput St ream instances. 
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nderedImage im, Stri Writes an image to the specified file. 
me, File output) 


nderedImage im, Stri Writes an image to an 
me, ImageOutputstrea ImageOutputStream. 


nderediImage im, String Writes an image to an OutputStream. 
me, OutputStream output) 


As you can glean from the provided methods, the image input/output framework provides 
us with a convenient way of using image codecs. As of Java 7, the following image format 
plugins were implemented by javax.imageio: 


e BMP 
e GIF 

e JPEG 
e PNG 

e WBMP 


The TIFF is, as you can see, not on the list of image file formats. TIFFs are a common file 
format and, in 2001, macOS, with the release of MacOS X, used the format extensively. 


The Java 9 platform includes ImageReader and ImageWriter plugins for the TIFFs. These 
plugins have been written in Java and have been bundled in the new 
javax.imageio.plugins.tiff package. 


Platform logging API and service [JEP-264] 


The Java 9 platform includes a new logging API enabling platform classes to log messages. 
It has a commensurate service for manipulating the logs. Before we go too far into what is 

new regarding the logging API and service, let's review java.util.logging.api which 
was introduced in Java 7. 
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The java.util.logging package 


The java.util.logging package includes classes and interfaces that collectively comprise 
Java's core logging features. This functionality was created with the following goals: 


e Problem diagnosis by end users and system administrators 
e Problem diagnosis by field service engineers 
e Problem diagnosis by the development organization 


As you can see, the primary purpose was to enable maintenance of remote software. 
The java.util.logging package has two interfaces: 


e public interface Filter 
e Purpose: This provides fine-grain control over logged data 
e Method: 
e isLoggable(LogRecord record) 


e public interface LoggingMxXBean 
e Purpose: This is the logging facility's management interface 
e Methods: 
e getLoggerLevel (String loggerName) 


e getLoggerNames () 
e getparentLoggerName (String loggerName) 


e setLoggerLevel (String loggerName, String 
levelName) 


The following table provides the java.util. logging package classes, along with a brief 
description regarding what each class provides in respect to logging functionality and 
management: 


ConsoleHandler public class ConsoleHandler | Publishes log records to 
extends StreamHandler System.err 


ErrorManager public class ErrorManager Used to process errors during 
extends Object logging 

FileHandler public class FileHandler File logging 
extends StreamHandler 
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Formatter public abstract class For formatting LogRecords 
Formatter extends Object 

Handler public abstract class Exports Logger messages 
Handler extends Object 


Level public class Level Controls level of logging. The 
Object implements levels, in descending order, 
Serializable are--severe, warning, info, 
config, fine, finer, and finest 


Logger public class Logger extends Logs messages 
Object 


LoggingPermission]public final class Securit yManager checks 
LoggingPermission extends this 
BasicPermission 


LogManager public class LogManager For maintaining shared state 
between loggers and logging 
services 


LogRecord public class LogRecord Passed between handlers 
extends Object implements 
Serializable 
MemoryHandler lic class MemoryHandler Buffers requests in memory 
tends Handler 


Formatter lic class SimpleFormatter |Provides human-readable 
nds Formatter LogRecord metadata 


SocketHandler lic class SocketHandler Network logging handler 
tends StreamHandler 
StreamHandler lic class StreamHandl Stream-based logging 
tends Handler handler 
XMLFormatter public class XMLFormatter Formats logs into XML 
extends Formatter 


Next, let's review what changes were made in Java 9. 
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Logging in Java 9 
Prior to Java 9, there were multiple logging schemas available, including 
java.util. logging, SLF4J, and Log4J. The latter two are third-party frameworks that 


have separate facade and implementation components. This pattern has been replicated in 
the new Java 9 platform. 


Java 9 introduced changes to the java.base module so that it would handle logging 
functions and not rely on the java.util.logging API. It has separate facade and 
implementation components. This means that when using third-party frameworks, the JDK 
only needs to provide the implementation component and return platform loggers that 
work with the requesting logging framework. 


As you can see in the following illustration, we use the java.util.ServiceLoader API to 
load our LoggerFinder implementation. The JDK uses a default implementation if a 
concrete implementation is not found using the system class loader: 


java.util.ServiceLoader API 
LoggerFinder Implementation 


Load 
java.util.ServiceLoader Use Concrete 
API using the system Implementation 
class loader 


Locate 
java.util.ServiceLoader 
API 


No concrete implementation found 


Use JDK internal 
default LoggerFinder 
implementation 
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XML Catalogs [JEP-268] 


JEP 268, titled XML Catalogs, focused on creating a standard XML Catalog API to support 
the OASIS XML Catalogs Standard v1.1. The new API defines catalog and catalog-resolve 
abstractions so that JAXP processors can use them. In this section, we will look at the 
following: 


e The OASIS XML Catalog standard 
e JAXP processors 

e XML Catalogs prior to Java 9 

e Java 9 platform changes 


The OASIS XML Catalog standard 


XML (eXtensible Markup Language) Catalogs are XML documents consisting of catalog 
entries. Each entry pairs an identifier to another location. OASIS is a not-for-profit 
consortium with the mission of advancing open standards. They published the XML catalog 
standard, version 1.1., in 2005. This standard has two basic use cases: 


e Map an external identifier to a URI reference 
e Map a URI reference to another URI reference 
Here is a sample XML catalog entry: 


<public publicId="-//Packt Publishing Limited//Mastering Java 9//EN" 
uri="https://www.packtpub.com/application-development/mastering-java-9"/> 


The complete OASIS XML Catalog standard can be found at the official site: https: //www. 
oasis-—open.org/committees/download.php/14809/xml-catalogs.html 
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JAXP processors 


The Java API for XML processing is referred to as JAXP. As its name suggests, this API is 
used for parsing XML documents. There are four related interfaces: 


e DOM: Document Object Model parsing 

e SAX: Simple API for XML parsing 

e StAX: Streaming API for XML parsing 

e XSLT: Interface to transform XML documents 


XML Catalogs prior to Java 9 


The Java platform has had an internal catalog resolver since JDK 6. There was no public 
API, so external tools and libraries were used to access the functionality. Moving into Java 
9, the goal was to make the internal catalog resolver a standard API for common use and 
ease of support. 


Java 9 platform changes 


The new XML Catalog API, delivered with Java 9, follows the OASIS XML Catalogs 
standard, v1.1. Here are the feature and capability highlights: 


e Implements Ent ityResolver 


e Implements URIResolver 
e Creation of XML Catalogs is possible via the CatalogManager 
e CatalogManager will be used to create CatalogResolvers 


e OASIS open catalog file semantics will be followed 
e Map an external identifier to a URI reference 


e Map a URI reference to another URI reference 


e CatalogResolvers will implement the JAXP Ent ityResolver interface 


e CatalogResolvers will implement the JAXP URIResolver interface 
e The SAX XMLFilter will be supported by the resolver. 


Since the new XML Catalog API will be public, the pre-Java 9 internal catalog resolver will 
be removed, as it will no longer be necessary. 
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Convenience factory methods for collections 
[JEP-269] 


The Java programming language does not support collection literals. Adding this feature to 
the Java platform was proposed in 2013 and revisited in 2016, but it only gained exposure as 
a research proposal, not for future implementation. 


evaluates to an aggregate type, such as an array, list, or map" (nttp://openjdk. 


Oracle's definition of a collection literal is "a syntactic expression form that 
Gp java.net/jeps/186). 


Of course, that is until Java 9 is released. Implementing collection literals in the Java 
programming language is reported to have the following benefits: 


e Performance improvement 
e Increased safety 
e Reduction of boilerplate code 


Even without being part of the research group, our knowledge of the Java programming 
language clues us in to additional benefits: 


e Ability to write shorter code 
e Ability to write space-efficient code 
e Ability to make collection literals immutable 


Let's look at two cases--using collections before Java 9, and then with the new support for 
collection literals in the new Java platform. 


Using collections before Java 9 


Here is an example of how we would create our own collections prior to Java 9. This first 
class defines the structure for PlanetCollection. It has the following components: 


e A single instance variable 

e A one argument constructor 
e Mutator/setter method 

e Accessor/getter method 

e Method to print the object 
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Here is the code implementing the preceding listed constructor and methods: 


public class PlanetCollection 
{ 
// Instance Variable 
private String planetName; 


// constructor 
public PlanetCollection (String name) 


{ 


setPlanetName (name) ; 


// mutator 
public void setPlanetName (String name) 


{ 


this.planetName = name; 


// accessor 
public String getPlanetName () 
{ 


return this.planetName; 


public void print () 
{ 
System.out.printin(getPlanetName () ); 


} 


Now, let's look at the driver class that populates the collection: 


import java.util.ArrayList; 


public class OldSchool 
{ 
private static ArrayList<PlanetCollection> myPlanets = 
new ArrayList<>(); 


public static void main(String[] args) 
{ 

add("Earth"); 

add("Jupiter"); 

add("Mars"); 

add ("Venus"); 

add("Saturn"); 

add ("Mercury"); 
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add ("Neptune"); 
add("Uranus"); 
add("Dagobah") ; 
add ("Kobol"); 
for (PlanetCollection orb : myPlanets) 
{ 
orb.print (); 


public static void add(String name) 

{ 
PlanetCollection newPlanet = new PlanetCollection (name) ; 
myPlanets.add(newPlanet) ; 


} 


Here is the output from this application: 


Declaration GJ Console X 


<terminated> OldSchool [Java Application] /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java (Aug 9, 2017, 7:02:41 PM) 
Earth 

Jupiter 

Mars 

Venus 


Saturn 
Mercury 
Neptune 
Uranus 
Dagobah 
Kobol 


This code is, unfortunately, very verbose. We populated our collection in static initializer 
blocks instead of using a field initializer. There are other methods of populating our list, but 
they are all more verbose than they should have to be. These other methods have additional 
problems, such as the need to create extra classes, the use of obscure code, and hidden 
references. 


Let's now take a look at the solution to this problem, provided by the new Java 9 platform. 
We will look at what is new in the next section. 
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Using new collection literals 


In order to rectify the currently required code verbosity in creating collections, we need 
library APIs for creating collection instances. Look at our pre-Java 9 code snippet in the 
previous section and then consider this possible refactoring: 


PlanetCollection<String> myPlanets = Set.of ( 
"Earth", 
"Jupiter", 
"Mars", 
"Venus", 
"Saturn", 
"Mercury", 
"Neptune", 
"Uranus", 
Dagobah", 
"Kobol"); 


" 


This code is highly human-readable and not verbose. 
The new implementation will include static factory methods on the following interfaces: 


e List 
e Map 
e Set 


So, we are now able to create unmodifiable instances of List collections, Map collections, 
and Set collections. They can be instantiated with the following syntax: 

e List.of(a, b, c, d, e); 

e Set.of(a, b, c, qd, e); 

e Map.of(); 


The Map collections will have a set of fixed arguments. 


Platform-specific desktop features [JEP-272] 


The exciting JEP-272 was to create a new public API so that we can write applications with 
access to platform-specific desktop features. These features include interacting with task 
bars/docks and listening for application and system events. 
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The macOS X com. apple.eawt package was an internal API and, starting with Java 9, is no 
longer accessible. In support of Java 9's new embedded platform-specific desktop features, 
apple.applescript classes are being removed from the Java platform without 
replacement. 


This effort had several objectives: 


e Create a public API to replace the functionality in com. apple. {east,eio} 


e Ensure OS X developers do not loose functionality. To this end, the Java 9 
platform has replacements for the following packages: 
e com.apple.eawt 


e com.apple.eio 
e Provide developers with a near-common set of features for platforms (that is, 


Windows and Linux) in addition to OS X. The common features include: 
e Login/logout handler with event listeners 


e Screen lock handler with event listeners 


e Task bar / dock actions to include: 
e Requesting user attention 


e Indicating task progress 
e Action shortcuts 


The new API will be added to the java. awt .Desktop class. 


Enhanced method handles [JEP-274] 


The Enhanced Method Handles JEP-274 was to improve the following listed classes, to 
make common usage easier with improved optimizations: 


e MethodHandle class 
e MethodHandles class 
e MethodHandles. Lookup class 


The listed classes are all part of the java. lang. invoke package, which has been updated 
as part of the Java 9 platform. The improvements were made possible through the use of 
lookup refinement and MethodHandle combinations for loops and try...finally 
blocks. 
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In this section, we will look at the following regarding JEP-274: 


e Reason for the enhancement 
e Lookup functions 

e Argument handling 

e Additional combinations 


Reason for the enhancement 


This enhancement stemmed from developer feedback and the desire to make the 
MethodHandle, MethodHandles, and MethodHandles. Lookup classes much easier to use. 
There was also the call to add additional use cases. 


The changes resulted in the following benefits: 


e Enabled precision in the usage of the MethodHandle API 
e Instantiation reduction 
e Increased JVM compiler optimizations 


Lookup functions 


Changes regarding lookup functions, for the Java 9 platform, include the following: 


e MethodHandles can now be bound to non-abstract methods in interfaces 
e The lookup API allows class lookups from different contexts 


The MethodHandles. Lookup. findSpecial (Class<?> refs, String name, 
MethodType type, Class<?> specialCaller) class has been modified to permit 
locating super-callable methods on interfaces. 


In addition, the following methods have been added to the Met hodHandles. Lookup class: 


e Class<?> findClass (String targetName) 


e Class<?> accessClass(Class<?> targetClass) 
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Argument handling 


Three updates were made to improve MethodHandle argument handling for the Java 9 
platform. These changes are highlighted as follows: 


e Argument folding using foldArguments (MethodHandle target, 
MethodHandle combinator) did not previously have a position argument. 

e Argument collection using the 
MethodHandle.asCollector(Class<?> arrayType, int 
arrayLength) method did not previously support collecting the 
arguments into an array except for the trailing element. This has 
been changed, and there is now an additional asCollector 
method to support that functionality in Java 9. 


e Argument spreading using the MethodHandle.asSpreader (Class<?> 
arrayType, int arrayLength) method spreads the contents of the trailing 
array to a number of arguments, in a reverse method of argument collection. 
Argument spreading has been modified to support the expansion of an array 
anywhere in the method signature. 


The new method definitions for the updated asCollector and 
asSpreader methods are provided in the next section. 


Additional combinations 


The following addition combinations have been added to support the ease of use and 
optimizations for the MethodHandle, MethodHandles, and MethodHandles. Lookup 
classes of the java. lang. invoke package in the Java 9 platform: 


e Generic loop abstraction: 
e Me 


thodHandle loop(MethodHandle[] . . . clauses) 


e While loops: 
e MethodHandle whileLoop(MethodHandle init, 


MethodHandle pred, MethodHandle body) 


e Do...while loops: 
em 


w 


hodHandle doWhileLoop (MethodHandle init, 


MethodHandle body, MethodHandle pred) 


eu 
et 
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e Counting loops: 
e MethodHandle countedLoop (MethodHandle iterations, 


hodHandle init, MethodHandle body) 


e Data structure iteration: 
hodHandle iteratedLoop (MethodHandle iterator, 
hodHandle init, MethodHandle body) 


e Try...finally blocks: 


e MethodHandle tryFinally (MethodHandle target, 
hodHandle cleanup) 


et 
e Argument handling: l 
e Argument spreading: 
e MethodHandle asSpreader(int pos, Class<?> 
arrayType, int arrayLength) 


e Argument collection: 


e MethodHandle asCollector(int pos, 
Class<?> arrayType, int arrayLength) 


e Argument folding: 


e MethodHandle foldArguments (MethodHandle 
target, int pos, MethodHandle combiner) 


Enhanced deprecation [JEP-277] 


There are two facilities for expressing deprecation: 


e @Deprecated annotation 


e @deprecated javadoc tag 


These facilities were introduced in Java SE 5 and JDK 1.1, respectively. The @Deprecated 
annotation was intended to annotate program components that should not be used because 
they were deemed dangerous and/or there was a better option. That was the intended use. 
Actual use varied including and because warnings were only provided at compile time; 
there was little reason to ignore the annotated code. 


The Enhanced Deprecation JEP-277 was taken on to provide developers with clearer 
information regarding the intended disposition of the APIs in the specification 
documentation. Work on this JEP also resulted in a tool for analyzing a program's use of 
deprecated APIs. 
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To support this fidelity in information, the following components have been added to the 
java.lang.Deprecated annotation type: 


e forRemoval (): 
e Returns Boolean t rue if the API element has been slated for future 
removal 
e Returns Boolean false if the API element has not been slated for 
future removal but is deprecated 
e Default is false 


e since (): 
e Returns a string containing the release or version number, at which 
point the specified API was marked as deprecated 


What the @Deprecated annotation really means 


When an API, or methods within an API, has/have been marked with the @Deprecated 
annotation, one or more of the following conditions typically exists: 


e There are errors in the API for which there is no plan to fix them 
e Using the API is likely to result in errors 

e The API has been replaced by another API 

e The API is experimental 


Summary 


In this chapter, we covered 16 JEPs that were incorporated into the Java 9 platform. These 
JEPs cover a wide range of tools and updates to APIs to make developing with Java easier, 
with greater optimization possibilities for our resulting programs. Our review included a 
look at the new HTTP client, changes to Javadoc and the Doclet API, the new JavaScript 
parser, JAR and JRE changes, the new Java-level JVM compiler interface, the new support 
for TIFF images, platform logging, XML Catalog support, collections, and the new platform- 
specific desktop features. We also looked at enhancements to method handling and the 
deprecation annotation. 


In the next chapter, we will cover concurrency enhancements introduced with the Java 9 
platform. Our primary focus will be the support for reactive programming that is provided 
by the flow class API. We will also explore additional concurrency enhancements 
introduced in Java 9. 
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Concurrency and Reactive 
Programming 


In the previous chapter, we covered several Java Enhancement Proposals (JEPs) that were 
incorporated into the Java 9 platform. These JEPs represented a wide range of tools and 
updates to APIs to make developing with Java easier, with greater optimization possibilities 
for our Java applications. We looked at the new HTTP client, changes to Javadoc and the 
Doclet API, the new JavaScript parser, JAR and JRE changes, the new Java-level JVM 
compiler interface, the new support for TIFF images, platform logging, XML catalog 
support, collections, and the new platform-specific desktop features. We also looked at 
enhancements to method handling and the deprecation annotation. 


In this chapter we will cover concurrency enhancements introduced with the Java 9 
platform. Our primary focus will be the support for reactive programming, a concurrency 
enhancement that is provided by the Flow class API. Reactive programming is a new 
concept for Java 9, so we will take an exploratory approach to the topic. We will also 
explore additional concurrency enhancements introduced in Java 9. 


Specifically, we will cover the following topics: 


e Reactive programming 

e The new Flow API 

e Additional concurrency updates 
e Spin-wait hints 
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Reactive Programming 


Reactive programming is when applications react to an asynchronous data stream as it 
occurs. The following image illustrates the flow: 


o? o 
OR 


® f 
Data Stream / merc) 


OF 
@2,e° 


Reacts to 


Asynchronous data 


Reactive programming is not a fancy software engineering term only used by academics. It 
is, in fact, a programming model that can result in much greater efficiencies as opposed to 
the more common method of having applications iterate over data that is in memory. 


There is more to reactive programming. First, let's consider that the data stream is provided 
by a publisher in an asynchronous manner to the subscriber. 


Data streams are a binary input/output of strings and primitive data types. 
The DataInput interface is used for an input stream and the Dat aOutput 
interface is used for output streams. 


Processors, or a chain of processors, can be used to transform the data stream without the 
publisher or subscriber being impacted. In the following example, the Processors work on 
the stream of data without Publisher or Subscriber involvement, or even awareness: 
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Publisher Subscriber 
@® ® . 
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Data Stream 


D)? ee j 


Reacts to 


Asynchronous data 


In addition to greater efficiency, reactive programming represents several additional 
benefits, which are highlighted here: 


e The code base can be less verbose, making it: 
e Easier to code 


e Easier to maintain 
e Easier to read 


e Stream processing results in memory efficiencies 
e This is a solution for a variety of programming applications 
e Less boiler-plate code needs to be written, so development time can be focused 
on programming core functionalities 
e The following types of programming require less time and code: 
e Concurrency 
e Low-level threading 
e Synchronization 


Reactive programming standardization 


There are standards in many aspects of software development, and reactive programming 
has not escaped this. There is a Reactive Streams initiative to standardize asynchronous 
stream processing. The specific focus, in the context of Java, is with the JVM and JavaScript. 
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The Reactive Streams initiative aims at tackling the issue of governing how the data stream 
is exchanged between threads. As you will recall from the previous section, the idea of 
processors is predicated on there being no impact on the publisher or receiver. This no- 
impact mandate stipulates that the following are not required: 


e Data buffering 
e Data translation 
e Conversion 


The basic semantics of the standard define the regulation of data stream element 
transmission. This standard was specifically established for delivery with the Java 9 
platform. Reactive Streams includes a library that will help developers convert from 
org.reactivestreams and java.util.concurrent.Flow namespaces. 


The key to being successful with reactive programming and the Reactive Streams 
standardization is understanding the relevant terminology: 


Demand refers to the subscriber's request for more elements as well 
as referring to the total number of elements requested that have not 
been fulfilled by the publisher yet. 


Demand Demand also refers to the total number of elements requested that 
have not been fulfilled by the publisher yet. 

External External access coordination for thread safety. 

synchronization 


Non-obstructing Methods are said to be non-obstructing if they rapidly execute 
without the requirement for heavy computations. Non-obstructing 
methods do not delay a subscriber's thread execution. 


NOP execution is execution that can be called repeatedly without 
e Sr aa to the calling thread. 


[Responsivity | This term refers to a component's | This term refers to a component's ability to respond. — | to respond. 


Return normally Return normally refers to when there are no errors--the normal 
condition. The onError method is the only way permitted by the 
standard to inform the subscriber of a failure. 
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One of the following methods: 
e cancel 


onComplete 


onError 


onNext 
onSubscribe 
request 


You can obtain the standard on Maven Central (https: //search.maven.org). Here is the 
standard from Maven Central as of the publication date of this book: 


<dependency> 
<grouplid>org.reactivestreams</groupId> 
<artifactId>reative-streams</artifactId> 
<version>1.0.1</version> 

</dependency> 


<dependency> 
<grouplId>org.reactivestreams</groupId> 
<artifact>reactive-streams-tck</artifactId> 
<version>1.0.0</version> 
<scope>test</scope> 

</dependency> 


In the next section, we will look at the Flow APIs in the Java 9 platform, as they correspond 
to the Reactive Streams specification. 


The New Flow API 


The Flow class is part of the java.util.concurrent package. It helps developers 
incorporate reactive programming in their applications. The class has one method, 
defaultBufferSize(), and four interfaces. 


The defaultBufferSize() is a static method that returns the default buffer size for 
publishing and subscribing buffering. This default value is 256 and it is returned as an int. 
Let's look at the four interfaces. 
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The Flow.Publisher interface 


The Flow. Publisher interface is a functional interface. A Publisher is a producer of data 
sent to subscribers: 


@FunctionaliInterface 
public static interface Flow.Publisher<T> 


This functional interface can serve as a lambda expression assignment target. It only takes 
one argument--the subscribed item type <T>. It has one method: 


e void onSubscribe(Flow.Subscription subscription) 


The Flow.Subscriber interface 


The Flow. Subscriber interface is used to receive messages and its implementation is 
shown here: 


public static interface Flow.Subscriber<T> 


This interface is set up to receive messages. It only takes one argument--the subscribed item 
type <T>. It has the following methods: 


e void onComplete () 


e void onError (Throwable throwable) 


e void onNext (T item) 


e void onSubscribe(Flow.Subscription subscription) 


The Flow.Subscription interface 


The Flow. Subscription interface ensures that only subscribers receive what is requested. 
Also, as you will see here, a subscription can be cancelled at anytime: 


public static interface Flow.Subscription 
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This interface does not take any arguments and is the linkage that controls the messages 
between instances of Flow. Publisher and Flow. Subscriber. It has the following 
methods: 


e void cancel () 


e void request (long n) 


The Flow.Processor interface 


The Flow.Processor interface can serve as both a Subscriber anda Publisher. The 
implementation is provided here: 


static interface Flow.Processor<T,R> extends Flow.Subscriber<T>, 
Flow.Publisher<R> 


This interface takes two arguments--the subscribed item type <T> and the published item 
type <R>. It does not have its own methods, but does inherit the following method from 
java.util.concurrent.Flow.Publisher: 


e void subscribe (Flow.Subscriber<? super T> subscriber) 


Flow.Processor also inherits the following methods from the 
java.util.concurrent.Flow. Subscriber interface: 


e void onComplete() 


e void onError (Throwable throwable) 


e void onNext (T item) 


e void onSubscribe(Flow.Subscription subscription) 


Sample implementation 


In any given implementation of reactive programming, we will have a Subscriber that 
requests data and a Publisher that provides the data. Let's first look at a sample 
Subscriber implementation: 


import java.util.concurrent.Flow.*; 


public class packtSubscriber<T> implements Subscriber<T> 


{ 


private Subscription theSubscription; 
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// We will override the four Subscriber interface methods 


@Override 
public void onComplete () 
{ 


System.out.printin("Data stream ended"); 


@Override 
public void onError (Throwable theError) 


{ 


theError.printStackTrace(); 


@Override 
public void onNext (T theItem) 
{ 


System.out.printin("Next item received: " + thelItem); 
theSubscription.request (19); // arbitrary number for 
example purposes 


@Override 
public void onSubscribe (Subscription theSubscription) 


{ 
this.theSubscription = theSubscription; 
theSubscription. request (19); 


} 


As you can see, implementing the Subscriber is not difficult. The heavy work is done with 
the processors in-between the Subscriber and Publisher. Let's look at a sample 
implementation where the Publisher publishes a data stream to subscribers: 


import java.util.concurrent.SubsmissionPublisher; 


// First, let's create a Publisher instance 
SubmissionPublisher<String> packtPublisher = new 
SubmissionPublisher<>(); 


// Next, we will register a Subscriber 
PacktSubscriber<String> currentSubscriber = new 
PacktSubscriber<>(); 

packtPublisher.subscribe (currentSubscriber) ; 
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// Finally, we will publish data to the Subscriber and 
close the publishing effort 
System.out.printin("||---- Publishing Data Stream ----||"); 


packtPublisher.close(); 
System.out.printin("||---- End of Data Stream Reached HET 


Additional Concurrency Updates 


The More Concurrency Updates Java Enhancement Proposal, JEP 266, aimed to improve 
the use of concurrency in Java. In this section, we will briefly explore the concept of Java 
concurrency and look at related enhancements to the Java 9 platform: 


e Java concurrency 
e Supporting Reactive Streams 
e CompletableFuture API enhancements 


Java concurrency 


In this section, we will start with a brief explanation of concurrency, then look at system 
configurations, cover Java threads, and then look at the concurrency improvements. 


Concurrency explained 


Concurrent processing has been around since the 1960s. In those formative years, we 
already had systems that permitted multiple processes to share a single processor. These 
systems are more clearly defined as pseudo-parallel systems because it only appeared that 
multiple processes were being simultaneously executed. Our computers today still operate 
in this manner. The difference between the 1960s and current day is that our computers can 
have multiple CPUs, each with multiple cores, which better supports concurrency. 


Concurrency and parallelism are often used as interchangeable terms. 
Concurrency is when multiple processes overlap, although the start and 
stop times could be different. Parallelism occurs when tasks start, run, and 
stop at the same time. 
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System configurations 


There are several different processor configurations that need to be considered. This section 
features two common configurations. The first configuration is that of shared memory and 
is illustrated here: 


n 


Processors 


As you can see, the shared memory system configuration has multiple processors that all 
share a common system memory. The second featured system configuration is a distributed 
memory system: 


With the distributed memory system, each processor has its own memory and each 
individual processor is fully linked with the other processors, making for a distributed 
system that is fully linked. 
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Java threads 


A thread in Java is a program execution and is built into the JVM. The Thread class is part 
of the java. lang package (java. lang. Thread). Threads have priorities that control in 
what order the JVM executes them. While the concept is simple, implementation is not. Let's 
start by taking a close look at the Thread class. 


The Thread class has two nested classes: 


e public static enum Thread.State 


e public static interface Thread.UncaughtExceptionHandler 


There are three instance variables for managing thread priorities: 


e public static final int MAX_PRIORITY 
e public static final int MIN_PRIORITY 
e public static final int NORM_PRIORITY 


The Thread class has eight constructors, all of which allocate a new Thread object. Here are 
the constructor signatures: 


) 


hread(Runnable target) 


e public Thread 
e public 
e public Thread(Runnable target, String name) 
tring name) 


e public Thread(ThreadGroup group, Runnable target) 


hread 


T ( 
T ( 
T ( 
e public Thread ( 
T ( 
e public T ( 
T ( 


e public Thread 
long stackSize 


hreadGroup group, Runnable target, String name, 


S 
T 
ThreadGroup group, Runnable target, String name) 
T 
) 
T 


e public Thread(ThreadGroup group, String name) 


The Thread class also has 43 methods, six of which have been deprecated. The remaining 
methods are listed here, save for the accessors and mutators which are listed separately. 
You can consult the documentation for details about each of these methods: 


e public static int activeCount () 


e public final void checkAccess () 


e protected Object clone() throws CloneNotSupportedException 


èe public static Thread currentThread () 
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e pu 


blic 
blic 
blic 
bile 
blic 
blic 


static void dumpStack () 


static int enumerate(Thread[] array) 


static boolean holdsLock (Object obj) 
void interrupt () 
static boolean interrupted() 


final boolean isAlive() 


blic 


final boolean isDaemon () 


blic 


boolean isInterrupted () 


e join methods: 


e public final void join() throws InterruptedException 


e public final void join(long millis) throws 
InterruptedException 


e public final void join(long millis, int nano) throws 
InterruptedException 


e public void run() 


e sleep methods: 


e public static void sleep(long mills) throws 
InterruptedException 


e public static void sleep(long mills, int nano) 
throws InterruptedException 


e public void start () 


e public String toString () 


e public static void yield() 


Here is the list of accessors/getters and mutators/setters for the Thread class: 


e accessors/getters: 


e public static Map<Thread, StackTraceElement []> 
getAllStacktraces () 


e public ClassLoader getContextClassLoader () 


e public static Thread.UncaughtExceptionHandler 
getDefaultUncaughtExceptionHandler () 


e public long getId() 
e public final String getName () 


e public final int getPriority () 


e public StackTraceElement[] getStackTrace() 
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e public Thread.State getState() 
e public final ThreadGroup getThreadGroup () 


e public Thread.UncaughtExceptionHandler 
getUncaughtExceptionHandler () 


e mutators/setters: 
e public void setContextClassLoader (ClassLoader cl) 


e public final void setDaemon (boolean on) 


e public static void 
setDefaultUncaughtExceptionHandler (Thread.Uncaught 
ceptionHandler eh) 


ea] 
x 


e public final void setName (String name) 


e public final void setPriority(int newPriority) 


e public void 
setUncaughtExceptionHandler (Thread. UncaughtException 
Handler eh) 


In Java, concurrency is commonly referred to as multithreading. As indicated earlier, 
managing threads, and especially multithreads, requires great fidelity in control. Java 
employs a couple of techniques including the use of locks. Code segments can be locked to 
ensure that only a single thread can execute that code at any given time. We can lock classes 
and method with the use of the synchronized keyword. Here is an example of how to lock 
an entire method: 


public synchronized void protectedMethod () 
{ 


} 


The next code snippet demonstrates how to use the synchronized keyword to lock blocks of 
code within a method: 


public class unprotectedMethod () 
{ 


public int doSomething(int tValue) 
{ 
synchronized (this) 
{ 
if (tValue != 0) 
{ 
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// do something to change tValue 
return tValue; 
} 
} 
} 
} 


Concurrency improvements 


The ability to employ multiple threads in our Java applications stands to greatly improve 
efficiency and leverage the increasing processing capabilities of modern computers. The use 
of threads in Java gives us great granularity in our concurrency controls. 


Threads are at the core of Java's concurrency functionality. We can create a thread in Java by 
defining a run method and instantiating a Thread object. There are two methods of 
accomplishing this set of tasks. Our first option is to extend the Thread class and override 
the Thread. run method. Here is an example of that approach: 


class PacktThread extends Thread 
{ 


public void run() 


{ 


} 
} 


Thread varT = new PacktThread(); 


// This next line is start the Thread by executing 
the run() method. 
varT.start(); 
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A second approach is to create a class that implements the Runnable interface and passing 
an instance of the class to the constructor of the Thread. Here is an example: 


class PacktRunner implements Runnable 
{ 


public void run() 


{ 


} 
} 


PacktRunner varR = new PacktRunner(); 
Thread varT = new Thread (varR); 


// This next line is start the Thread by executing the 
run() method. 
varT.start(); 


Both of these methods work equally well, and which one you use is considered to be the 
developer's choice. Of course, if you are looking for additional flexibility, the second 
approach is probably a better one to use. You can experiment with both methods to help 
you make your determination. 


CompletableFuture API enhancements 


The CompleteableFuture<T> class is part of the java.util.concurrent package. The 
class extends the Object class and implements the Future<T> and CompletionStage<T> 
interfaces. This class is used to annotate threads that can be completed. We can use the 
CompletableFuture class to represent a future result. When the complete method is used, 
that future result can be completed. 


It is important to realize that if multiple threads attempt to simultaneously complete (finish 
or cancel), all but one will fail. Let's look at the class and then look at the enhancements. 
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Class details 


The CompleteableFuture<T> class has one internal class that marks asynchronous tasks: 


public static interface 
CompletableFuture.AsynchronousCompletionTask 


The constructor for the CompleteableFuture<T> class has to be in sync with the provided 
constructor signature, and it takes no arguments. The class has the following methods 


organized by what 
Returns a Complet 


e public 
extends 
e public 
acceptE 
Consume 


e public 
acceptE 
Consume 


e public 
extends 


e public 


applyTo 
Functio 


e public 


applyTo 
Functio 


e public 
e public 


e public 
Throwab 


e public 
T; Thro 


e public 
T, Thre 


e public 
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other, 


they return. 
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T> other, Functi 
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<U> CompletableFu 
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<U> CompletableFu 
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CompletionStage<T 


CompletableFuture 
Runnable action) 


<Void> acceptEither (CompletionStage<? 


T> other, Consumer<? super T> action) 


<Void> 
tionStage<? extends T> other, 
on) 


<Void> 


tionStage<? extends T> other, 
on, Executor executor) 


ture<U> applyToEither (CompletionStage<? 
on<? super T, U> fn) 


ture<U> 

etionStage<? extends T> other, 
n) 

ture<U> 

etionStage<? extends T> other, 
n, Executor executor) 


tedStage<U> completedStage (U value) 


tionStage<U> failedStage (Throwable ex) 


ture<U> handle (BiFunction<? super T, 
fn) 


ture<U> handleAsync (BiFunction<? super 
U> fn) 


ture<U> handleAsync (BiFunction<? super 
U> fn, Executor executor) 


> minimalCompletionStage () 


<Void> runAfterBoth (CompletionStage<?> 
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èe public CompletableFu 


runAf 


e public CompletableFu 


runAf 


tor executor) 


ture<Void> 
terBothAsync (CompletionStage<?> other, 
ture<Void> 
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terBitherAsync (CompletionStage<?> other, 


runAf 
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Runnable action, 


Runnable action) 


Runnable action) 


Runnable action, 


e public CompletableFuture<T> whenComplete (BiConsumer<? super T, 
? super Throwable> action) 


e public CompletableFuture<T> whenCompleteAsync (BiConsumer<? 


super 


T, 


? super Throwable> 


action) 


e public CompletableFuture<T> whenCompleteAsync (BiConsumer<? 


super 


T, 


? super Throwable> 


action, 
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e public Comple 
action) 


e public Comple 
action) 
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e public Comple 


T> 


èe public <U> CompletableFuture<Void> 


thenAcceptBoth (CompletionStage<? extends U> other, 
U> action) 
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e public <U> CompletableFuture<U> thenApplyAsync(Function<? super 
T, ? extends U> fn) 


e public <U> CompletableFuture<U> thenApplyAsync(Function<? super 
T, ? extends U> fn, Executor executor) 


e public <U, V> CompletableFuture<V> 
thenCombine (CompletionStage<? extends U> other, BiFunction<? 
super T, ? super U, ? extends V> fn) 


e public <U, V> CompletableFuture<V> 
thenCombineAsync (CompletionStage<? extends U> other, 
BiFunction<? super T, ? super U, ? extends V> fn) 


e public <U, V> CompletableFuture<V> 
thenCombineAsync (CompletionStage<? extends U> other, 
BiFunction<? super T, ? super U, ? extends V> fn, Executor 
executor) 


e public <U> CompletableFuture<U> thenCompose (Function<? super T, 
? extends CompletionStage<U>> fn) 


e public <U> CompletableFuture<U> thenComposeAsync (Function<? 
super T, ? extends CompletionStage<U>> fn) 


e public <U> CompletableFuture<U> thenComposeAsync (Function<? 
super T, ? extends CompletionStage<U>> fn, Executor executor) 


e public CompletableFuture<Void> thenRun(Runnable action) 


e public CompletableFuture<Void>thenRunAsync (Runnable action) 


e public CompletableFuture<Void>thenRunAsync (Runnable action, 
Executor executor) 


These methods return a CompleteableFuture: 


e public static CompletableFuture<Void> 
allof (CompletableFuture<?>...cfs) 


e public static CompletableFuture<Object> 
anyOf (CompletableFuture<?>... cfs) 


e public CompletableFuture<T> completeAsync (Supplier<? extends T> 
supplier, Executor executor) 


e public CompletableFuture<T> completeAsync (Supplier<? extends T> 
supplier) 


e public static <U> CompletableFuture<U> completedFuture(U value) 
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e public CompletableFuture<T> completeOnTimeout (T value, long 
timeout, TimeUnit unit) 


e public CompletableFuture<T> copy () 


e public CompletableFuture<T> exceptionally (Function<Throwable, ? 
extends T> fn) 


èe public static <U> CompletableFuture<U> failedFuture (Throwable 
ex) 


e public <U> CompletableFuture<U> newIncompeteFuture () 


e public CompletableFuture<T> orTimeout (long timeout, TimeUnit 
unit) 

e public static ComletableFuture<Void> runAsync (Runnable 
runnable) 

e public static CompletableFuture<Void> runAsync (Runnable 
runnable, Executor executor) 

e public static <U> CompletableFuture<U> supplyAsync (Supplier<U> 
supplier) 


èe public static <U> CompletableFuture<U> supplyAsync (Supplier<uU. 
supplier, Executor executor) 


e public CompletableFuture<T> toCompletableFuture () 


These methods return a Executor: 


e public Executor defaultExecutor () 


e public static Executor delayedExecutor(long delay, Timeunit 
unit, Executor executor) 


e public static Executor delayedExecutor(long delay, Timeunit 
unit) 


These methods return a boolean: 


e public boolean cancel (boolean mayInterruptIfRunning) 
e public boolean complete(T value) 


e public boolean completeExceptionally (Throwable ex) 


e public boolean isCancelled() 


e public boolean isCompletedExceptionally () 


èe public boolean isDone() 
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No return type: 


e public void obtrudeException(Throwable ex) 


e public void obtrudeValue(T value) 


Additional methods: 


e public T get(long timeout, TimeUnit unit) throws 
InterruptedException, ExecutionException, TimeoutException 


e public T get() throws InterruptedException, ExecutionException 


èe public T getNow(T valuelIfAbsent) 


e public int getNumberOfDependents () 
èe public T join() 


e public String toString () 


Enhancements 


The CompleteableFuture<T> class received the following enhancements as part of the 
Java 9 platform: 


e Added time-based enhancements: 
e This enables completions based on lapsed time 


e Delayed executions are now also supported 


e Significant enhancement to subclasses: 
e Extending CompletableFuture is easier 


e Subclasses support alternative default executors 


Specifically, the following methods were added in Java 9: 


e newIncompleteFuture () 


e defaultExecutor () 


e copy () 


e minimalCompletionStage () 


e completeAsync() 
e orTimeout () 


e completeOnTimeout () 
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e delayedExecutor () 
e completedStage () 
e failedFuture () 

e failedStage() 


Spin-Wait Hints 


With concurrency, we need to ensure that threads waiting to be executed actually get 
executed. The concept of spin-wait is a process that continually checks for a true condition. 
The aim of Java Enhancement Proposal 285 was to create an API that permits Java code to 
issue hints that a spin loop is currently being executed. 


While this is not a feature that every Java developer will use, it can be useful for low-level 
programming. The hint system simply issues hints--indications, and performs no other 
actions. Justifications for adding these hints include the following assumptions: 


e A spin loop's action time can be improved when using a spin hint 
e Use of spin hints will reduce thread-to-thread latency 

e CPU power consumption will be reduced 

e Hardware threads will execute faster 


This hint functionality will be contained in a new onSpinWait () method as part of the 
java.lang.Thread class. Here is an example of implementing the onSpinWait () method: 


volatile boolean notInReceiptOfEventNotification; 


while ( notInReceiptOfEventNotification ); 
{ 

java.lang.Thread.onSpinWait (); 
} 


// Add functionality here to read and process the event 
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Summary 


In this chapter, we covered concurrency enhancements introduced with the Java 9 platform. 
We took a deep look at concurrency both as a core Java concept and with an eye to what 
Java 9 is delivering. We also explored the Flow class API that supports reactive 
programming, a new concept in Java 9. In addition, we explored concurrency enhancements 
and the new spin-wait hints introduced in Java 9. 


In the next chapter, we will highlight the security enhancements introduced in Java 9 along 
with practical examples. 
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security Enhancements 


In the last chapter, we covered concurrency enhancements introduced with the Java 9 
platform. We took an in-depth look at concurrency both as a core Java concept and as a 
series of enhancements for Java 9. We also explored the Flow class API that supports 
Reactive Programming, anew concept in Java 9. In addition, we explored concurrency 
enhancements and the new Spin-Wait hints introduced in Java 9. 


In this chapter, we will look at several small changes made to the JDK that involve security. 
The size of these changes does not reflect their significance. The security enhancements 
introduced with the Java 9 platform provide developers with a greater ability to write and 
maintain applications that are more secure than previously possible. 


Specifically, we will review the following content areas in this chapter: 


e Datagram Transport Layer Security 

e Creating PKCS12 keystores 

e Improving security application performance 

e TLS application-layer protocol negotiation extension 
e Leveraging CPU instructions for GHASH and RSA 

e OCSP stapling for TLS 

e DRBG-based SecureRandom implementations 
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Datagram Transport Layer Security 


Datagram Transport Layer Security (DTLS), is a communications protocol. The protocol 
provides a layer of security for datagram-based applications. DTLS permits secure 
communications and is based on the Transport Layer Security (TLS) protocol. Embedded 
security helps ensure messages are not forged, tampered with, or eavesdropped. 


Let's review the relevant terminology: 


e Communication protocol: A set of rules that govern how information is 
transmitted. 


Datagram: A structured transfer unit. 


Eavesdropping: Undetected listening to in-transit data packets. 
e Forgery: Transmission of a packet with falsified sender. 


Network packet: A formatted unit of data for transmission. 


e Tampering: The altering of data packets after the sender transmits them and 
before the intended receiver receives them. 


e TLS protocol: The most common network security protocol. Uses, as an example, 
IMPA and POP for email. 


The DTLS Java Enhancement Proposal 219 is aimed at creating an API for the DTLS 
versions 1.0 and 1.2. 


In the sections that follow, we will look at each of the DTLS versions, 1.0 and 1.2, and then 
review the changes to the Java 9 platform. 


DTLS protocol version 1.0 


DTLS protocol version 1.0 was established in 2006 and provides communications security 
for datagram protocols. Here are the basic characteristics: 


e Permits client/server applications to communicate without permitting: 
e Eavesdropping 


e Tampering 
e Message forgery 
e Based on the TLS protocol 
e Provides security guarantees 
e The DLS protocol's datagram semantics are preserved 
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The following diagram illustrates where the Transport Layer fits into the overall schema of 
SSL/TLS protocol layers and protocols for each layer: 


DTLS protocol version 1.0 provides detailed specifications with the major areas of coverage 
listed as follows: 


e Ciphers: 
e Anti-replay block cipher 


e New cipher suites 
e Standard (or null) stream cipher 


Denial of service countermeasures 


e Handshake: 
e Message format 


e Protocol 
e Reliability 
e Messages: 
e Fragmentation and reassembly 
e Loss-insensitive messaging 
e Size 
e Timeout and retransmission 
e Packet loss 


e Path Maximum Transition Unit (PMTU) discovery 


Record layer 
e Record payload protection 
e Reordering 


Replay detection 


Transport layer mapping 
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DTLS protocol version 1.2 


DTLS protocol version 1.2 was published in January 2012 and is copyrighted by the Internet 
Engineering Task Force (IETF). This section shares code samples that illustrate the changes 
in version 1.2. 


The following code illustrates the TLS 1.2 handshake message header. This format supports: 


e Message fragmentation 
e Message loss 
e Reordering 


// Copyright (c) 2012 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


struct 

{ 
HandshakeType msg_type; 
uint24 length; 


uint16 message_seq; // New field 
uint24 fragment_offset; // New field 
uint24 fragment_length; // New field 


select (HandshakeType) 
{ 


case hello_request: HelloRequest; 
case client_hello: ClientHello; 
case hello_verify_request: HelloVerifyRequest; // New type 


case server_hello: ServerHello; 
case certificate:Certificate; 
case server_key_exchange: ServerKeyExchange; 


case certificate_request: CertificateRequest; 
case server_hello_done:ServerHelloDone; 
case certificate_verify: CertificateVerify; 
case client_key_exchange: ClientKeyExchange; 
case finished: Finished; 
} body; 
} Handshake; 


The code presented in this section is from the DTLS protocol 
documentation and is republished here in accordance with IETF's Legal 
Provisions Relating to IETF Documents. 
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The record layer contains the information that we intend to send into records. The 
information starts off inside a DTLSPlaintext structure and then, after the handshake 
takes place, the records are encrypted and are eligible to be sent by the communication 
stream. The record layer format follows with new fields in version 1.2 annotated with the 
// New field in-code comments as follows: 


// Copyright (c) 2012 IETF Trust and the persons identified 
as authors of the code. All rights reserved. 


struct 

{ 
ContentType type; 
ProtocolVersion version; 
uint16 epoch; // New field 
uint48 sequence_number; // New field 
uint16 length; 
opaque fragment [DTLSPlaintext.length]; 

} DTLSPlaintext; 


struct 

{ 
ContentType type; 
ProtocolVersion version; 
uint16 epoch; // New field 
uint48 sequence_number; // New field 
uint16 length; 
opaque fragment [DTLSCompressed. length] ; 

} DTLSCompressed; 


Struct 
{ 
ContentType type; 
ProtocolVersion version; 
uint16 epoch; // New field 
uint48 sequence_number; // New field 
uint16 length; 
select (CipherSpec.cipher_type) 
{ 


case block: GenericBlockCipher; 
case aead: GenericAEADCipher; // New field 
} fragment; 
} DTLSCiphertext; 
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Finally, here is the updated handshake protocol: 


// Copyright (c) 2012 IETF Trust and the persons identified 
as authors of the code. All rights reserved. 


enum { 

hello_request (0), client_hello(1), 
server_hello(2), 

hello_verify_request (3), // New field 
certificate(11), server_key_exchange (12), 
certificate_request (13), server_hello_done (14), 
certificate_verify(15), client_key_exchange(16), 
finished(20), (255) } HandshakeType; 


struct { 
HandshakeType msg_type; 
uint24 length; 


uint16 message_seq; // New field 
uint24 fragment_offset; // New field 
uint24 fragment_length; // New field 


select (HandshakeType) { 
case hello_request: HelloRequest; 
case client_hello: ClientHello; 
case server_hello: ServerHello; 
case hello_verify_request: HelloVerifyRequest; // New field 
case certificate:Certificate; 
case server_key_exchange: ServerKeyExchange; 
case certificate_request: CertificateRequest; 
case server_hello_done:ServerHelloDone; 
case certificate_verify: CertificateVerify; 
case client_key_exchange: ClientKeyExchange; 
case finished: Finished; 

} body; } Handshake; 


struct { 
ProtocolVersion client_version; 
Random random; 
SessionID session_id; 
opaque cookie<0..2%8-1>; // New field 
CipherSuite cipher_suites<2..2%16-1>; 
CompressionMethod compression_methods<1..2*%8-1>; } ClientHello; 


struct. { 
ProtocolVersion server_version; 
opaque cookie<0..2%8-1>; } HelloVerifyRequest; 
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DTLS support in Java 9 


Java 9's implementation of the DTLS API is transport-independent and light-weight. The 
design considerations for the API were as follows: 


e Read timeouts will not be managed 
e The implementation will use a single TLS record for each wrap/unwrap operation 
e The application, not the API, will be required to: 

e Determine timeout values 

e Assemble out-of-order application data 


The DTLS is a protocol used to secure data from the application layer before that data is 
passed to a transport layer protocol. DTLS is a good solution for encrypting and 
transmitting real-time data. Caution should be exercised so that we do not introduce 
vulnerabilities in our application's implementation. Here are security considerations 
specific to implementing DTLS in your Java 9 applications: 


e Implement DTLS v1.2, since that is the latest version supported by Java 9. 

e Avoid Rivest-Shamir-Adleman (RSA) encryption. If RSA must be used, add 
addition security to your private keys since this is a weak point for RSA. 

Use 192 bits or more when using the Elliptic Curve Diffie-Hellman (ECDH) 
anonymous key agreement protocol. The 192-bit value is based on a National 
Institute of Standards and Technology (NIST) recommendation. 

The use of Authenticated Encryption with Associated Data (AEAD), a form of 
encryption, is highly recommended. AEAD provides authenticity, confidentiality, 
and integrity assurances on the data being encrypted and decrypted. 


e Always implement the renegot iat ion_info extension when implementing 
handshake renegotiation. 

e Establish a Forward Secrecy (FS) capability in all Java applications using a 
communication protocol. Implementing FS ensures past session encryption keys 
are not compromised when long-term encryption keys are compromised. Ideally 
a Perfect Forward Secrecy (PFS), where each key is only valid for a single 
session, would be used in the Java applications that call for the greatest security 
of transmitted data. 
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Creating PKCS12 keystores 


The Java 9 platform provides increased security for keystores. In order to appreciate the 
changes ushered in by Java Enhancement Proposal 229, create PKCS12 keystores by default, 
we will first review the concept of keystores, look at the KeyStore class, and then look at 
the changes. 


Keystore primer 


The concept of a KeyStore is relatively simple. It is essentially a database file, or data 
repository file, that stores public key certificates and private keys. The Keystore will be 
stored in the /jre/lib/security/cacerts folder. As you will see in the next section, this 
database is managed by Java's java. security.KeyStore class methods. 


KeyStore features include: 


e Contains one of the following entry types: 
e Private keys 


e Public key certificates 


e Unique alias string names for every entry 
e Password protection for each key 


Java Keystore (JKS) 


The java.security.KeyStore class is the storage facility for cryptographic keys and 
certificates. This class extends java.lang.Object, see as follows: 


public class KeyStore extends Object 


There are three types of entries managed by a KeyStore, each implements the 
KeyStore.Entry interface, one of the three interfaces provided by the KeyStore class. The 
Entry implementations are defined in the following table: 


KeyStore.PrivateKeyl e Contains the PrivateKey and can store it ina 


protected format 
e Contains the certificate chain for the public key 
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e Contains the SecretKey and can store it ina 
protected format 


KeyStore.TrustedCertifcatel e Contains a single public key Certificate from 
an external source 


This class has been part of the Java platform since version 1.2. It has one constructor, three 
interfaces, six sub-classes, and several methods. The constructor definition is: 


protected KeyStore (KeyStoreSpi keyStoresSpi, 
Provider provider, String type) 


The KeyStore class contains the following interfaces: 


e public static interface KeyStore.Entry: 
e This interface serves as a marker for KeyStore entry types and 
contains no methods. 


e public static interface KeyStore.LoadStoreParameter: 

e This interface serves as a marker for load and store parameters and 
has the following method that returns null or the parameter used 
to protect the KeyStore data: 

e getProtectionParameter () 


e public static interface KeyStore.ProtectionParameter: 
e This interface serves as a marker for KeyStore protection 
parameters and contains no methods. 


The java.security.KeyStore class also contains the six nested classes listed as follows. 


Builder 


The KeyStore. Builder class is used when you want to defer the instantiation of a 
Keystore: 


public abstract static class KeyStore.Builder extends Object 


[ 331 ] 


www.EBooksWorld.ir 


Security Enhancements 


This class provides the necessary information for instantiating a KeySt ore object. The class 
has the following methods: 


e public abstract KeyStore getKeyStore() throws KeyStoreException 


e public abstractKeyStore.ProtectionParameter 
getProjectionParameter (String alias) throws KeyStoreException 


e Three options for newInstance: 
e public static KeyStore.Builder newInstance (KeyStore 

keyStore, KeyStore.ProtectionParameter 
protectionParameter) 


e public static KeyStore.Builder newInstance (String 
type, Provider provider, File file, 
KeyStore.ProtectionParameter protection) 


e public static KeyStore.Builder newInstance (String 
type, Provider provider, 
KeyStore.ProtectionParameter protection) 


The CallbackHandlerProtection class 


The KeyStore.CallbackHandlerProtection class definition is as follows: 


public static class KeyStore.CallbackHandlerProtection extends 
Object implements KeyStore.ProtectionParameter 


This class provides a Protect ionParameter to encapsulate a CallbackHandler and has 
the following method: 


public CallbackHandler getCallbackHandler () 


The PasswordProtection class 


The KeyStore.PasswordProtection class definition is as follows: 


public static class KeyStore.PasswordProtection extends Object 
implements KeyStore.ProtectionParameter, Destroyable 
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This call provides an implementation of Protect ionParameter that is password-based. 
The class has the following methods: 


e public void destroy() throws DestroyFailedException: 
e This method clears the password 


e public char[] getPassword(): 
e Returns a reference to the password 


e public boolean isDestroyed(): 
e Returns true if the password was cleared 


The PrivateKeyEntry class 


The KeyStore.PrivateKeyEntry class definition is as follows: 


public static final class KeyStore.PrivateKeyEntry extends 
Object implements KeyStore.Entry 


This creates an entry to hold a PrivateKey and the corresponding Certificate chain. 
This class has the following methods: 


e public Certificate getCertificate(): 
e Returns the end entity Certificate from the Certificate chain 


e public Certificate[] getCertificateChain(): 
e Returns the Certificate chain as an array of Certificates 


e public PrivateKey getPrivateKey (): 
e Returns the PrivateKey from the current entry 


e public String toString(): 
e Returns the PrivateKeyEntry asa String 


The SecretKeyEntry class 


The KeyStore.SecretKeyEntry class definition is as follows: 


public static final class KeyStore.SecretKeyEntry extends 
Object implements KeyStore.Entry 
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This class holds a SecretKey and has the following methods: 


e public SecretKey getSecretKey (): 
e Returns the entry's SecretKey 


e public String toString(): 
e Returns the SecretKeyEntry aS a String. 


The TrustedCertificateEntry class 


The KeyStore.TrustedCertificateEntry class definition is as follows: 


public static final class KeyStore.TrustedCertificateEntry extends 
Object implements KeyStore.Entry 


This class holds a trusted Certificate and has the following methods: 


e public Certificate getTrustedCertificate(): 
e Returns the entry's trusted Certificate 


e public String toString(): 
e Returns the entry's trusted Certificate asa String 


The key to using this class is understanding the flow. First, we must load the KeyStore, 
using the get Instance method. Next we request access to the KeyStore instance. Then, 
we have access to read and write to the Object: 


The following code snippet shows the load-request-access implementation: 


try { 
// KeyStore implementation will be returned for the default type 
KeyStore myKS = KeyStore.getInstance (KeyStore.getDefaultType())j; 


// Load 
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myKS.load(null, null); 
// Instantiate a KeyStore that holds a trusted certificate 
TrustedCertificateEntry myCertEntry = 

new TrustedCertificateEntry (generateCertificate()); 


// Assigns the trusted certificate to the "pack.pub" alias 
myKS.setCertificateEntry("packt.pub", 
myCertEntry.getTrustedCertificate()); 
return myKS; 

} 

catch (Exception e) { 
throw new AssertionError(e); 


} 


PKCS12 default in Java 9 


Prior to Java 9, the default KeyStore type was Java KeyStore (JKS). The Java 9 platform 
now uses PKCS as the default KeyStore type, more specifically, PKCS12. 


PKCS is the acronym for Public Key Cryptography Standards. 


This change to PKCS provides stronger cryptographic algorithms as compared to JKS. As 
you would expect, JDK 9 will still be compatible with JKS to support previously developed 
systems. 


Improving security application performance 


Java Enhancement Proposal 232, titled Improving Security Application Performance, was 
focused on performance improvements when running applications with a security manager 
installed. Security managers can result in processing overhead and less than ideal 
application performance. 
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This is an impressive undertaking as current CPU overhead when running security 
managers is estimated to result in 10-15% performance degradation. It is not feasible to 
completely remove the CPU overhead as some CPU processing is required to run the 
security manager. That being said, the intention of this proposal (JEP-232) was to decrease 
the overhead percentage as much as possible. 


This effort resulted in the following optimizations, each detailed in subsequent sections: 


e Security policy enforcement 
e Permission evaluation 

e Hash code 

e Package checking algorithm 


Security policy enforcement 


JDK 9 uses ConcurrentHashMap for mapping Protect ionDomain to 
PermissionCollection. ConcurrentHashMap is typically used for high concurrency in 
applications. It has the following characteristics: 


e Thread safe 

e Enter map does not need to be synchronized 
e Fast reads 

e Writes use locks 

e No object-level locking 

e Locking at a very granular level 


The ConcurrentHashMap class definition follows: 


public class ConcurrentHashMap<K, V> extends AbstractMap<K, V> 
implements ConcurrentMap<K, V>, Serializable 


In the preceding class definition, K refers to the type of keys maintained by the hash map 
and V indicates the type of mapped values. There is a KeySet View sub-class and several 
methods. 
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There are three additional classes related to enforcing security policy--P rotect ionDomain, 
PermissionCollection, and SecureClassLoader: 


e The Protect ionDomain class is used to encapsulate a group of classes so that 
permissions can be granted to the domain. 
e The PermissionCollection class represents a collection of permission objects. 


e The SecureClassLoader class, which extends the ClassLoader class, provides 
additional functionality for defining classes with permissions for retrieval by the 
system policy. In Java 9, this class uses ConcurrentHashMap for increased 
security. 


Permission evaluation 


Under the category of permission evaluation, three optimizations were made: 


e The identifyPolicyEntries list previously had policy provider code for 
synchronization. This code has been removed in JDK 9. 


e PermissionCollection entries are now stored in a ConcurrentHashMap. They 
were previously stored as a HashMap in a Permission class. 


e Permissions are now stored in concurrent collections in subclasses of 
PermissionCollection. 


The java.Security.CodeSource package 


A hash code is an object-generated number that is stored in a hash table for rapid storage 
and retrieval. Every object in Java has a hash code. Here are some characteristics and rules 
for hash codes: 


e Hash codes are the same for equal objects within a running process 
e Hash codes can change between execution cycles 
e Hash codes should not be used as keys 


The Java 9 platform includes a modified hashCode method of 
java.security.CodeSource to optimize DNS lookups. These can be processor intensive, 
so a String version of the code source URL is used to compute hash codes. 
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The CodeSource class definition follows: 
public class CodeSource extends Object implements Serializable 
This class has the following methods: 


e public boolean equals (Object obj): Returns true if the objects are equal. 
This overrides the equals method in the Object class. 


e public final Certificate[] getCertificates (): Returns an array of 
certificates. 


e public final CodeSigner[] getCodeSigners (): Returns an array of the 
code signers associated with the CodeSource. 


e public final URL getLocation (): Returns the URL. 
e public int hashCode (): Returns the hash code value for the current object. 


e public boolean implies (CodeSource codesource): Returns true if the 
given code source meets the following criteria: 
e is not null 
e object's certificates are not null 
e object's location is not null 


e public String toString (): Returns a String with information about the 
CodeSource to include the location and certificates. 


Package checking algorithm 


Java 9's final performance improvement when running applications with a security 
manager installed, came in the form of the java. lang. SecurityManager package 
enhancements. Specifically, the checkPackageAccess method's package checking 
algorithm was modified. 
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The java.lang.SecurityManager class allows applications to implement security policy 
on specific operations. The public void checkPackageAccess (String pkg) method, 
of this class receives a comma-delimited list of restricted packages from the the 
getProperty method. As illustrated here, depending on the evaluation, the 
checkPackageAccess method can throw one of two exceptions: 


If calling thread does not have permission. 


If the package name argument is null. 


TLS application-layer protocol negotiation 
extension 


Java Enhancement Proposal 244, simply enhanced the javax.net.ssl package so that it 
supports the Transport Layer Security (TLS) ALPN (Application Layer Protocol 
Negotiation) extension. This extension permits application protocol negotiation for TLS 
connections. 
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TLS ALPN extension 


The ALPN is a TLS extension and can be used to negotiate which protocol to implement 
when using a secure connection. ALPN represents an efficient means of negotiating 
protocols. As indicated in the following diagram, there are five basic steps to TLS 
handshakes: 


The javax.net.ssl package 


The java.net .ssl package contains classes relating to secure socket packages. This 
permits us to use SSL as an example, for the reliable detection of errors introduced to the 
network byte stream. It also provides the ability to encrypt the data as well as provide 
authentication of client and server. 


This package includes the following interfaces: 


e public interface HandshakeCompletedListener extends 
EventListener 


e public interface HostnameVerifier 
e public interface KeyManager 


e public interface ManagerFactoryParameters 
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e public abstract class X509ExtendedKeyManager extends Object 
implements X509KeyManager 


e public abstract class X509ExtendedTrustManager extends Object 
implements x509TrustManager 


The java.net.ssl package extension 


The change to the java.net .ssl package in the Java 9 platform is that it now supports the 
TLS ALPN extension. Key benefits of this change are: 


e TLS clients and servers can now use multiple application-layer protocols, which 
may or may not use the same transport-layer port 

e The ALPN extension permits clients to prioritize application-layer protocols it 
supports 

e Servers can select a client protocol and for the TLS connection 

e Supports HTTP/2 


The following illustration was previously presented as the five basic steps to TLS 
handshakes. Updated for Java 9 and presented here, the illustration indicates where the 
protocol names are shared between the client and server: 
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Once the client's list of application layer protocols is received, the server can select the 
server's preferred intersection value and externally scan initial plain text ClientHellos 
and select an ALPN protocol. An application server will do one of the following: 


e Select any of the supported protocols 

e Decide that the ALPN values (remotely offered and locally supported) are 
mutually exclusive 

e Ignore the ALPN extension 


Other key behaviors with regards to the ALPN extension: 


e The server can alter connection parameters 

e After the SSL/TLS handshake starts, the application can query to see if an ALPN 
value has been selected yet 

e After the SSL/TLS handshake ends, the application can review which protocol 
was used 


A ClientHello is the first message in the TLS handshake. It has the following structure: 


sbruct 4 
ProtocolVersion client_version; 
Random random; 
SessionID session_id; 
CipherSuite cipher_suites<2..2%16-1>; 
CompressionMethod compression_methods<1..2%8-1>; 
Extension extensions<0..2%16-1>; 
} ClientHello; 


Leveraging CPU instructions for GHASH and 
RSA 


The self-descriptive title of Java Enhancement Proposal (JEP) 246, Leverage CPU 
Instructions for GHASH and RSA, provides great insight into its goal. The point of this JEP 
was to improve the performance of cryptographic operations, specifically GHASH and 
RSA. The performance improvement has been achieved in Java 9 by leveraging the newest 
SPARC and Intel x64 CPU instructions. 


This enhancement did not require new or modified APIs as part of the Java 9 platform. 


[ 343 ] 


www.EBooksWorld.ir 


Security Enhancements 


Hashing 


Galois HASH (GHASH) and Rivest-Shamir-Adleman (RSA) are crypto systems hashing 
algorithms. Hashes are a fixed length string or number generated from a string of text. 
Algorithms, specifically hashing algorithms, are devised so that the resultant hashes cannot 
be reverse engineered. We use hashing to store passwords that are generated with a salt. 


function to generate a password. Salts help protect against rainbow table 


Salts, in cryptology, are random data used as an input to a hashing 
© attacks and dictionary attacks. 


The following graphic illustrates the basics of how hashing works: 


As you can see, the hashing algorithm is fed plain text and a salt resulting in a new hashed 
password and the salt being stored. Here is the same graphic with sample input/output to 
demonstrate the functionality: 
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The validation process, the following diagram starts with the user entering their plain text 
password. The hashing algorithm takes that plain text and rehashes it with the stored salt. 
Then the resulting hashed password is compared to the stored one: 


OCSP stapling for TLS 


Online Certificate Status Protocol (OCSP) stapling is a method of checking the revocation 
status of digital certificates. The OCSP stapling approach for determining an SSL 
certificate's validity is assessed as being both safe and quick. The determination speed is 
achieved by permitting web servers to provide the validity information on its organic 
certificates instead of the lengthier process of requesting validating information from the 
certificate's issuing vendor. 


Online Certificate Status Protocol (OCSP) stapling was previously 
referred to as the Transport Layer Security (TLS) certificate status request 
extension. 
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OCSP stapling primer 


THE OCSP stapling process involves several components and validity checks. The 
following graphic illustrates the OCSP stapling process: 


Browser makes Server staples 
connection to web SSL certificate 
server hosting the SSL- with signed 
encrypted website time-stamp 


certificate status 
digital signed time-stamp 


As you can see, the process starts when the user attempts to open an SSL-encrypted website 
via their browser. The browser queries the web server to ensure the SSL-encrypted website 
has a valid certificate. The web server queries the certificate's vendor and is provided with 
both the certificate status and the digital signed time-stamp. The web server takes those two 
components (certificate status and digital signed time-stamp), staples them together, and 
returns the stapled set to the requesting browser. The browser can then check the validity of 
the time-stamp and decide whether to display the SSL-encrypted website or to display an 
error. 
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Changes for the Java 9 platform 


Java Enhancement Proposal 249, OCSP Stapling for TLS, implements OCSP stapling via 
the TLS certificate status request extension. OSCP stapling checks the validity of X.509 
certificates. 


X.509 certificates are digital certificates that use the X509 Public Key 
Infrastructure (PKI). 


Prior to Java 9, the certificate validity check (really, the check to see if the certificate has 
been revoked) can be enabled on the client side and has the following inefficiencies: 


e OCSP responder performance bottlenecks 

e Performance degradation based on multiple passes 

e Additional performance degradation if OCSP checking is performed client side 
e False fails when browsers do not connect to an OCSP responder 

e Susceptibility of denial of service attacks on OCSP responders 


The new OCSP stapling for TLS includes the following system property changes for the 
Java 9 platform: 


e jdk.tls.client.enableStatusRequestExtension: 
e Default setting: true 
e Enables status_request extension 
e Enables status_request_v2 extension 
e Enables processing CertificateStatus messages from server 


e jdk.tls.server.enableStatusRequestExtension: 
e Default setting: false 
e Enables OCSP stapling support server-side 
e jdk.tls.stapling.responseTimeout: 
e Default setting: 5000 milliseconds 
e Controls maximum time allocated by server to obtain OCSP 
responses 
e jdk.tls.stapling.cacheSize: 
e Default setting: 256 
e Controls maximum number of cache entries 
e Can set maximum to zero eliminates ceiling 
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e jdk.tls. 


e jdk.tls. 


e jdk.tls. 


e jdk.tls. 


stapling.cacheLifetime: 

e Default setting: 3600 seconds (1 hour) 

e Controls maximum lifetime of a cached response 

e Can set value to zero in order to disable cache lifetime 
stapling.responderURI: 

e Default setting: none 

e Can set a default URI for certificates without the Authority Info 

Access (AIA) extension 


e Does not override the AIA extension unless 
jdk.tls.stapling.Override property is set 


stapling.respoderOverride: 
e Default setting: false 
e Allows a jdk.tls.stapling.responderURI provided property 
to override AIA extension values 


stapling.ignoreExtensions: 
e Default setting: false 
e Disables OCSP extension forwarding as specified in 
status_request or status_request_v2 TLS extensions. 


The status_request and status_request_v2 TLS hello extensions are now supported 
by both client and server-side Java implementations. 


DRBG-based SecureRandom 
implementations 


Prior to Java 9, the JDK had two approaches to generating secure random numbers. One 
method, written in Java, used SHA1-based random number generation and was not terribly 
strong. The other method was platform-dependent and used preconfigured libraries. 


Deterministic Random Bit Generator (DRBG) is a method for generating random 
numbers. It has been approved by the National Institute of Standards and Technology 
(NIST), a branch of the U.S. Department of Commerce. DRBG methodologies include 
modern and stronger algorithms for generating secure random numbers. 
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Java Enhancement Proposal 273, DRBG-Based SecureRandom Implementations aimed to 
implement three specific DRBG mechanisms. These mechanisms are listed as follows: 


e Hash_DRBG 
e HMAC _DRBG 
e CTR_DRBG 


You can learn specifics about each of the DRBG mechanisms at http: // 
nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1. 
pdt 


Here are the three new APIs: 


e SecureRandom: New methods allowing the configuration of SecureRandom 
objects with the below listed configurable properties: 
e seeding 
e reseeding 
e random-bit-generation 


e SecureRandomSpi: new methods to implement the SecureRandom methods 


e SecureRandomParameter: new interface so input can be passed to the new 
SecureRandom methods 


Summary 


In this chapter, we looked at several small, but significant changes to the JDK that involve 
security. The featured security enhancements that are part of the Java 9 platform provide 
developers with the distinct ability to write and maintain applications that implement 
security. Specifically, we covered DTLS, keystores, improving security application 
performance, the TLS application-layer protocol negotiation extension, leveraging CPU 
instructions for GHASH and RSA, OCSP stapling for TLS, and DRBG-based SecureRandom 


implementations. 


In the next chapter we will explore the new command-line flags used in Java 9 as well as 
changes to various command-line tools. Our coverage will include managing the Java JVM 
run-time and compiler using the new command-line options and flags. 
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In the previous chapter, we looked at several security changes to the JDK. Java 9's security 
enhancements provide developers with the ability to write and maintain applications that 
implement security. Specifically, we covered datagram transport layer security, Keystores, 
improving security application performance, the TLS application-layer protocol negotiation 
extension, leveraging CPU instructions for GHASH and RSA, OCSP stapling for TLS, and 
DRBG-based SecureRandom implementations. 


In this chapter, we will explore several changes to the Java 9 platform with the common 
theme of command-line flags. Specifically, we will cover the following concepts: 


e Unified JVM logging 

e Compiler control 

e Diagnostic commands 

e Heap profiling agent 

e Removing your JHAT 

e Command-line flag argument validation 
e Compiling for older platform versions 


Unified JVM Logging [JEP 158] 


Creating a unified logging schema for the JVM was the central goal of JEP-158. Here is a 
comprehensive list of the goals of the JEP: 


e Create a JVM-wide set of command-line options for all logging operations 
e Use categorized tags for logging 
e Permit messages to have multiple tags, also referred to as tag sets 
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e Provide six levels of logging: 
e Error 


e Warning 

e Information 
e Debug 

e Trace 

e Develop 


Select which messages are logged based on levels 


Optionally direct logging to the console or a file 
e Print one line at a time and do not support interleaving within the 
same line 
e Permit output of multiple line logs (non-interleaved) 
e Format all logging messages so that they are easily human-read 
e Add decorations such as uptime, level, and tags 
e Like levels, select which messages are logged based on decorations 
e Convert pre-Java 9 tty>print logging to use unified logging as the output 
e Permit dynamic message configuration using jcmd and MBeans 
e Permit the ability to enable and disable individual log messages 
e Add ability to determine the order in which decorations are printed 


The unified logging changes to the JVM can be grouped into the five categories listed here: 


e Command-line options 
e Decorations 

e Levels 

e Output 

e Tags 


Let's briefly look at each of these categories. 


Command-line options 


The new command-line option, —Xlog, was added to the logging framework in Java 9. This 
command-line option has an extensive array of parameters and possibilities. The basic 
syntax is simply —Xlog followed by an option. Here is the formal basic syntax: 


-Xlog[:option] 
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Here is a basic example with the a11 option: 
-Xlog:all 

Here is the extensive command-line syntax used to configure the new unified logging: 
-Xlog[:option] 


option := [<what>] [: [<output>] [: [<decorators>] [:<output— 


options>]]] 


what 
selector 


tag-set 


tag 


level 


output 


decorators 


decorator 


output—options 


"help' 
'disable' 


<selector>[,...] 
<tag-set>[*] [=<level>] 


<tag>[+..] 
'all' 


name of tag 


trace 
debug 
info 
warning 
error 


'stderr' 
'stdout' 
[file=]<filename> 


<decorator>[,...] 
'none' 


time 

uptime 
timemillis 
uptimemillis 
timenanos 
uptimenanos 
pid 

tid 

level 

tags 


<output_option>[,...] 
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output—option := filecount=<file count> 
filesize=<file size in kb> 
parameter=value 
The following —Xlog examples are followed by a description: 
-Xlog:all 


In the preceding example, we are telling the JVM to take the following actions: 


e Log all messages 
e Use the info level 
e Provide output to stdout 


With this example, all warning messages will still be output to stderr. 


The next example, shown here, logs messages at the debug level: 
-Xlog:gc+trt*=debug 
In the preceding example, we are telling the JVM to take the following actions: 


e Log all messages tagged with, at a minimum, the gc and rt tags 
e Use the debug level 
e Provide output to stdout 
The next example pushes the output to an external file: 
-Xlog:disable - Xlog:rt=debug: rtdebug.txt 
In the preceding example, we are telling the JVM to take the following actions: 
e Disable all messages except those tagged with rt tags 


e Use the debug level 
e Provide output to a file named rtdebug.txt 
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Decorations 


In the context of Java 9's logging framework, decorations are metadata about the log 
message. Here is the alphabetic list of decorations that are available: 


level: The level associated with the logged message 

pid: PID = Processor IDentifier 

tags: The tag-set associated with the logged message 

tid: TID = Thread IDentifier 

time: Refers to current date and time using ISO-8601 format 
timemillis: Current time in milliseconds 

timenanos: Current time in nanoseconds 

uptime: Time, in seconds and milliseconds, since the JVM started 
uptimemillis: Time, in milliseconds, since the JVM started 
uptimenanos: Time, in nanoseconds, since the JVM started 


Decorations can be surpassed or included in unified logging output. Regardless of which 
decorations are used, they will appear in the output in the following order: 


CHONAUA WON H 


jai 
= 


time 
uptime 


. timemillis 
. uptimemillis 


timenanos 
uptimenanos 
pid 

tid 


. level 


tags 
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Levels 


Logged messages are individually associated with a verbosity level. As previously listed, 
the levels are error, warning, information, debug, trace, and develop. The following chart 
shows how the levels have an increasing level of verbosity in respect to how much 
information is logged. The develop level is for development purposes only and is not 
available in on-product application builds: 


Verbosity Levels 


error warning info debug trace develop 


Output 


The Java 9 logging framework supports three types of output with examples of direct use 
with the -xlog command-line syntax: 


In the following example, we provide output to stderr: 
-Xlog:all=warning:stderr:none 

The following example provides output to stdout: 
-Xlog:all=warning: stdout :none 

The following example writes the output to a text file: 


-Xlog:all=warning: file=logmessages.txt:none 
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Tags 

The new logging framework consists of a set of tags identified in the JVM. These tags can be 
changed in source code if needed. The tags should be self-identifying, such as gc for 
garbage collection. 


When more than one tag is grouped together, they form a tag-set. When we add our own 
tags via source code, each tag should be associated with a tag-set. This will help ensure the 
tags stay organized and easily human-readable. 


Compiler control [JEP 165] 


Controlling Java Virtual Machine compilers might seem like an unnecessary task, but for 
many developers, this is an important aspect of testing. Java Enhancement Proposal 165 
detailed a plan to implement runtime management of JVM compilers. This is accomplished 
with method-dependent compiler flags. 


In this section, we will start with a look at JVM compilation modes, then look at the 
compiler that can be controlled using the Java 9 platform. 


Compilation modes 


The changes in the Java 9 platform include granular control of both the cl and c2 JVM 
compliers. As you can see in the following illustration, the Java HotSpot JVM has two Just- 
in-Time (JIT) compilation modes--cl and c2: 


e Quick Startup 
e Optimization 


e Long-Running 
e Server-Side 
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The C1 and C2 compilation modes use different compilation techniques and, if used on the 
same code base, can produce different sets of machine code. 


C1 compilation mode 
The C1 compilation mode inside Java HotSpot VM is typically used for applications that 
have the following characteristics: 

e Quick startup 

e Increased optimization 

e Client-side 


C2 compilation mode 


The second compilation mode, C2, is used by applications with the following listed 
characteristics: 


e Long runtimes 
e Server-side 


Tiered compilation 


Tiered compilation allows us to use both c1 and c2 compilation modes. Starting with Java 8, 
tiered compilation is the default process. As illustrated here, the c1 mode is used at startup 
to help provide greater optimization. Then, once the app has sufficiently warmed up, the c2 
mode is employed: 
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Compiler control in Java 9 


Java 9 comes with the promise of the ability to have finite control over JVM compilers and 
to make changes at runtime. These additional abilities do not degrade performance. This 
permits greater fidelity of testing and testing optimization as we can run small compiler 
tests without having to relaunch the entire JVM. 


To control compiler operations, we need to create a directives file. These files contain 
compiler directives which consist of a set of options with values. Directive files essentially 
use a subset of JSON: 


The JavaScript Object Notation (JSON) format is used for data-interchange. The directive 
files have the following formatting differences from JSON: 


e int and doubles are the only supported number formats 

e Double forward slash (//) can be used for comment lines 

e Trailing commas (, ) can be used in arrays and objects 

e Escape characters are not supported 

e Option names are formatted as strings and do not have to be quoted 


You can learn more about JSON at http://www. json.org. 
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We can add our directive file using the following syntax at the command line: 


-XX:CompilerDirectivesFile=<file> 


Here is a shell example of a directives file: 


[ // Open square bracket marks the start of the directives fil 
{ // Open curly brace marks the start of a directive block 


// A directives block that applies specifically to the C1 mode 
elf 


// directives go her 
}, 
// A directives block that applies specifically to the C2 mode 
C2 f 


// directives go her 
}, 


// Here we can put a directives that do not apply to 
// a specific compiler mode 


ty 


{ // can have multiple directive blocks 


// directives go her 


c2: {4 
// directives go her 


] // Close square bracket marks the start of the directives fil 


Diagnostic commands [JEP 228] 


The Java Enhancement Proposal 228, Add More Diagnostic Commands, defined seven 
additional diagnostic commands to enhance the ability to diagnose the JDK and the JVM. 
The new diagnostic commands are detailed here. 
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The print_codegenlist command prints methods that are currently queued for 
compilation. Since cl and c2 compilation modes are on separate queues, this command 
would need to be issued to a specific queue. 


The dump_codelist diagnostic command will print the following listed information for 
the compiled methods: 


e Full signature 
e Address range 


e State 
e Alive 


e Nonentrant 
e Zombie 


In addition, the dump_codelist diagnostic command allows the output to be directed to 
stdout or to a specified file. Output can be in XML form or standard text. 


The print_codeblocks command allows us to print: 


e Code cache size 

e Code cache list 

e List of blocks in the code cache 
e Addresses for code blocks 


Th datadump_request diagnostic command sends a dump request to the Java Virtual 
Machine Tool Interface ()VMTI). This replaces the Java Virtual Machine Debug Interface 
(JVMDI) and the Java Virtual Machine Profiling Interface (JVMPI) interfaces. 


With the set_vmflag command, we can set a command-line flag or option in the JVM or 
the libraries. 


Th print_class_summary diagnostic command prints a list of all loaded classes as well as 
the structure of their inheritance. 


The print_utf£8pool command prints all UTF-8 string constants. 


[ 360 ] 


www.EBooksWorld.ir 


Command Line Flags 


Heap profiling agent [JEP 240] 


Java Enhancement Proposal 240 is titled Remove the JVM TI hprof Agent. Here are the key 
terms associated with this JEP and referenced in the title that might be new to you: 


e Tool Interface (TI): This is a native programming interface that allows tools to 
control the execution of applications that are being run inside the Java Virtual 
Machine. The interface also permits state inquiries. The full nomenclature for this 
tool is the Java Virtual Machine Tool Interface, or JVM TI. 

e Heap Profiling (HPROF): This is an internal JDK tool used for profiling a JVM's 
use of CPUs and the heap. The most common exposure developers have to hprof 
is the file that is generated when following a crash. The generated file contains a 
heap dump. 


The Java 9 JDK does not contain the hprof agent. It was removed largely because there are 
superior alternatives available. Here is a table of the related functionality: 


HPROF Functionality | Alternative 


Allocation Profiler Java VisualVM 
(heap=sites) 


CPU Profiler Java VisualVM 
(cpu=samples) Java Flight Recorder 
(cpu=times) 


Heap Dumps Internal JVM functionality: 
(heap=dump) *GC.heap_dump (icmd <pid> GC.heap_dump) 
e jmap -dump 


Interestingly, when HPROF was originally created, it was not intended to be used in 
production. In fact, it was only meant to test code for the JVM Tool Interface. So, with the 
advent of the Java 9 platform, the HPROF library (lLibhprof .so) will no longer be part of 
the JDK. 
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Removing your JHAT [JEP 241] 


The Java Heap Analysis Tool (JHAT) is used to parse Java heap dump files. The syntax for 
this heap dump file parsing tool is as follows: 
jhat 

[-stack <bool>] 

[-refs <bool>] 

[-port <port>] 

[-baseline <file>] 

[-debug <int>] 

[-version] 

[-h|-help] 

<file> 


Here is a quick look at the options associated with the JHAT command: 


Exclude indicated file from reachable objects N/A 
query 


baseline<filename> Specifies the baseline heap dump for use in N/A 
comparisons. 
Simply outputs the JHAT release number. N/A 


ZA Provides help text. N/A 
-help 


JHAT has been part of the Java platform since JDK-6 in an experimental form. It was not 
supported and has been deemed to be outdated. Starting with Java 9, this tool will no 


u 


longer be part of the JDK. 
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JVM command-line flag argument validation 
[JEP 245] 


In this chapter, you have gained exposure to much of the command-line flag usage with the 
Java 9 platform. Java Enhancement Proposal 245, titled Validate JVM Command-Line Flag 
Arguments, was created to ensure all JVM command-line flags with arguments are 
validated. The primary goals of this effort were: 


e Avoid JVM crashes 
e Provide error messages to inform of invalid flag arguments 


As you can see from the following graphic, there was no attempt to auto-correct the flag 
argument errors; rather, just to identify the errors and prevent the JVM from crashing: 


Identify flag 
argument errors 


correct errors 


A sample error message is provided here and indicates that the flag argument was out of 
range. This error would be displayed during the flag argument range check performed 
during the JVM's initialization: 


exampleFlag UnguardOnExecutionViolation = 4 is outside the allowed range [ 
Oo... 3] 
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Here are some specifics regarding this change to the Java platform: 


e Expand on the current globals .hpp source file to ensure complete flag default 
values and permissible ranges are documented 
e Define a framework to support adding new JVM command-line flags in the 
future: 
e This will include value ranges and value sets 
e This will ensure the validity checking will apply to all newly added 
command-line flags 
e Modify macro tables: 
e Add min/max for optional range 
e Add constraint entries for the following: 
e Ensure constraint checks are performed each time a 
flag changes 
e All manageable flags will continue to be checked 
while the JVM is running 


Compile for older platform versions [JEP 
247] 


The Java Compiler, javac, has been updated for Java 9 to ensure it can be used to compile 
Java programs to run on user-selected older versions of the Java platform. This was the 
focus of Java Enhancement Proposal 247, Compile for Older Platform Versions. 
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As you can see in the following screenshot, javac has several options including -source 
and -target. The javac presented in the following screenshot is from Java 8: 


eee @® edljr — -bash — 125x37 


Edwards-iMac:~ edljr$ javac -help 
Usage: javac <options> <source files> 
where possible options include: 
-9 Generate all debugging info 
=g: none Generate no debugging info 
-g:{lines, vars, source} Generate only some debugging info 
-nowarn Generate no warnings 
-verbose Output messages about what the compiler is doing 
-deprecation Output source locations where deprecated APIs are used 
-classpath <path> Specify where to find user class files and annotation processors 
-cp <path> Specify where to find user class files and annotation processors 
-sourcepath <path> Specify where to find input source files 
-bootclasspath <path> Override location of bootstrap class files 
-extdirs <dirs> Override location of installed extensions 
-endorseddirs <dirs> Override location of endorsed standards path 
-proc:{none, only} Control whether annotation processing and/or compilation is done. 
-processor <class1>[,<class2>,<class3>...] Names of the annotation processors to run; bypasses default discovery process 
-processorpath <path> Specify where to find annotation processors 
-parameters Generate metadata for reflection on method parameters 
-d <directory> Specify where to place generated class files 
-s <directory> Specify where to place generated source files 
-h <directory> Specify where to place generated native header files 
-implicit:{none, class} Specify whether or not to generate class files for implicitly referenced files 
-encoding <encoding> Specify character encoding used by source files 
source <release> Provide source compatibility with specified release 
-target <release> Generate class files for specific VM version 
-profile <profile> Check that API used is available in the specified profile 
-version Version information 
-help Print a synopsis of standard options 
-Akey [=value] Options to pass to annotation processors 
-X Print a synopsis of nonstandard options 
-J<f lag> Pass <flag> directly to the runtime system 
-Werror Terminate compilation if warnings occur 
@<filename> Read options and filenames from file 


Edwards-iMac:~ edljr$ J 


The -source option is used to dictate the Java version accepted by the compiler. The - 
target option informs which version of class files javac will produce. By default, javac 
generates class files in the most recent java version and that of the platform APIs. This can 
cause a problem when the compiled application uses APIs that are only available in the 
most recent platform version. This would render the application ineligible to run on older 
platform versions, despite what is dictated with the -source and -target options. 


To address the aforementioned problem, a new command-line option is introduced with the 
Java 9 platform. This option is the --release option and, when used, will automatically 
configure javac to generate class files that link against a specific platform version. The 
following screenshot shows the javac options with the Java 9 platform. As you can see, the 
new --release option is included: 
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Here is the syntax for the new option: 


javac --release <release> <source files> 
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Summary 


In this chapter we explored several changes to the Java 9 platform with the common theme 
of command-line flags. Specifically, we covered unified JVM logging, compiler control, new 
diagnostic commands, removal of the HPROF heap profiling agent, the removal of the 
JHAT, command-line flag argument validation, and the ability to compile for older platform 
versions. 


In the next chapter, we will focus on best practices with additional utilities provided with 
the Java 9 platform. These will include UTF-8, Unicode 7.0, Linux, and more. 
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In the last chapter, we explored several changes regarding command-line flags in Java 9. 
Specifically, we covered unified JVM logging, compiler control, new diagnostic commands, 
removal of the HPROF heap profiling agent, the removal of the Java Heap Analysis Tool 
(JHAT), command-line flag argument validation, and the ability to compile for older 
platform versions. 


In this chapter, we will focus on best practices with additional utilities provided with the 
Java 9 platform. Specifically, we will cover: 


e Support for UTF-8 

e Unicode 7.0.0 

e Linux/AArché4 port 

e Multi-resolution images 

e Common Locale Data Repository 


Support for UTF-8 


Unicode Transformation Format-8 (UTF-8) is a character set that encapsulates all Unicode 
characters using one to four 8-bit bytes. It is the byte-oriented encoded form of Unicode. 
UTF-8 is and has been the predominant character set for encoding web pages since 2009. 
Here are some characteristics of UTF-8: 


e Can encode all 1,112,064 Unicode code points 
e Uses one to four 8-bit bytes 

e Accounts for nearly 90% of all web pages 

e Is backward compatible with ASCII 

e Is reversible 
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The pervasive use of UTF-8 underscores the importance of ensuring the Java platform fully 
supports UTF-8. This mindset led to the Java Enhancement Proposal 226, UTF-8 property 
resource bundles. With Java 9 applications, we have the ability to specify property files that 
have UTF-8 encoding. The Java 9 platform includes changes to the ResourceBundle API to 
support UTF-8. 


Let's take a look at the pre-Java 9 ResourceBundle class, followed by what changes were 
made to this class in the Java 9 platform. 


The ResourceBundle class 


The following class provides developers with the ability to isolate locale-specific resources 
from a resource bundle. This class significantly simplifies localization and translation: 


public abstract class ResourceBundl xtends Object 


Creating resource bundles needs a purposeful approach. For example, let's imagine that we 
are creating a resource bundle that will support multiple languages for a business 
application. Our button labels, among other things, will be displayed differently depending 
on the current locale. So, for our example, we can create a resource bundle for our buttons. 
We can call it but tonResources. Then, for each locale, we can create a 
buttonResource_<identifier>. Here are some examples: 


e buttonResource_ja: for Japanese 
e buttonResource_uk: for UK English 
e buttonResource_it: for Italian 


e buttonResource_lh: for Lithuanian 


We can use a resource bundle with the same name as the base name for our default bundle. 
So, but tonResource would contain our default bundle. 


To obtain a locale-specific object, we make a call to the get Bundle method. An example 
follows: 


ResourceBundle = buttonResource = 
ResourceBundle.getBundle("buttonResource", currentLocale); 
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In the next sections we will examine the ResourceBundle class by looking at its nested 
class, field and constructor, and included methods. 


The nested class 


There is one nested class associated with the ResourceBundle class, that is the 
ResourceBundle.Control class. It provides callback methods that are used when the 
ResourceBundle.getBundle method is used: 


public static class ResourceBundle.Control extends Object 


The ResourceBundle.Control class has the following fields: 


e public static final List<String> FORMAT_CLASS 

e public static final List<String> FORMAT_DEFAULT 

e public static final List<String> FORMAT_PROPERTIES 
e public static final long TTL_DONT_CACHI 
èe public static final long TTL_NO_EXPIRATION_CONTROL 


GI 


The class has a single, empty constructor and the following methods: 
e getCandidateLocales(): 


public List<Locale> getCandidateLocales (String baseName, 
Locale locale) 


NullPointerException (if baseName or locale is null) 


Parameters | baseName: a fully qualified class name 
locale: the desired locale 


List of candidate locales 
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e getControl(): 


public static final ResourceBundle.Control getControl ( 
List<String> formats) 


Throws TllegalArgumentException (if formats is unknown) 
NullPointerException (if formats is null) 


Parameters | formats: These are the formats that will be returned by the 
ResourceBundle.Control.getFormats method 


A ResourceBundle.Control that supports the formats specified 


e getFallbackLocale(): 


public Locale getFallbackLocale(String baseName, Locale locale) 


‘Throws | Throws |Nul 1PointerException (if baseName or locale is null) 


Parameters | baseName: a fully qualified class name 
locale: the desired locale that could not be found with the 
ResourceBundle.getBundle method 


The fallback locale 


e getFormats(): 


public List<String> getFormats (String baseName) 


Throws NullPointerException (if baseName is null) 


Parameters | baseName: a fully qualified class name 
Returns A list of Strings with their formats so the resource bundles can be loaded 
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e getNoFallbackControl (): 


public static final ResourceBundle.Control 
getNoFallbackControl (List<String> formats) 


Throws TllegalArgumentException (if formats is unknown) 
NullPointerException (if formats is null) 


Parameters | formats: these are the formats that will be returned by the 
ResourceBundle.Control.getFormats method 

Returns A ResourceBundle.Control that supports the formats specified without a 
fallback locale. 


e getTimeToLive(): 


public long getTimeToLive (String baseName, Locale locale) 


NullPointerException (if baseName is null) 


Parameters | baseName: a fully qualified class name 
locale: the desired locale 


Zero or a positive millisecond that is offset from the cached time 


e needsReload(): 


public boolean needsReload(String baseName, Locale locale, 
String format, ClassLoader loader, ResourceBundle bundle, 
long loadTime) 


Throws NullPointerException (if any of the following listed parameters are null): 
e baseName 
locale 
format 
loader 
* bundle 
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Parameters | baseName: a fully qualified class name 
locale: the desired locale 
format: the resource bundle format 
loader: the ClassLoader that should be used to load the bundle 


bundle: the expired bundle 
loadTime: a time bundle was added to the cache 


true/false to indicate if the expired bundle needs to be reloaded 


e newBundle(): 


public ResourceBundle newBundle(String baseName, Locale locale, 
String format, ClassLoader loader, boolean reload) 


Throws ClassCastExcept ion (if the loaded class cannot be cast to 
ResourceBundle) 

ExceptionInInitializerError (if initialization fails) 
IllegalAccessException (if the class or constructor is not accessible) 
TllegalArgumentException (if the format is unknown) 
InstantiationException (if the class instantiation fails) 

IOException (resource reading error) 

NullPointerException (if any of the following listed parameters are null): 
e baseName 


locale 
Format 


loader 
SecurityException (if access to new instances is denied) 


Parameters | baseName: a fully qualified class name 
locale: the desired locale 
format: the resource bundle format 
loader: the ClassLoader that should be used to load the bundle 
reload: true/false flag indicating if the resource bundle has expired 


Instance of the resource bundle 
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e toBundleName (): 


public String toBundleName (String baseName, Locale locale) 


NullPointerException (if baseName or locale is null) 


Parameters | baseName: a fully qualified class name 
locale: the desired locale 
The bundle name 


e toResourceName (): 


public final String toResourceName (String bundleName, 
String suffix) 


NullPointerException (if bundleName or suffix is null) 


Parameters |bundleName: the name of the bundle 
suffix: the suffix for the file name 


Returns The converted resource name 


Fields and constructors 


The ResourceBundle class has one field as described here: 


protected Resourcebundle parent 


The parent bundle is searched by the getObject method when a specified resource is not 
found. 


The constructor for the ResourceBundle class is as shown here: 


public ResourceBundle() 
{ 
} 
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Methods 


The ResourceBundle class has 18 methods, each described here: 


e clearCache(): 


public static final void clearCache() 


public static final void clearCache (ClassLoader loader) 


e containsKey(): 


public boolean containsKey (String key) 


NullPointerException (if key is null) 


Parameters | key: resource key 


true/false depending on if the key is in the ResourceBundle or parent 
bundles 
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e getBundle(): 


public static final 


ResourceBundle getBundle(String baseName) 


Except ion (if the resource bundle for the provided 


Throws MissingResourcek j i 
baseName is not found) 
NullPointerException (if baseName is null) 


baseName: fully qualified class name 
Resource bundle based on the given baseName and the default locale 


public static final 


ResourceBundle getBundle (String baseName, 


Resourcebundle.Control control) 


Exception (if the passed control performs improperly) 
Exception (if the resource bundle for the provided 


baseName is not found) 


Throws IllegalArgumentE j i 
MissingResourceE j i 
NullPointerException (if baseName is null) 


Parameters | baseName: fully qualified class name 
control: the control provides information so the resource bundle can be 
loaded 


Resource bundle based on the given baseName and the default locale 


public static final 
Locale locale) 


ResourceBundle getBundle(String baseName, 


Except ion (if the resource bundle for the provided 


baseName is not found) 


Throws MissingResourceE j i 
NullPointerException (if baseName or locale is null) 


Parameters | baseName: fully qualified class name 
locale: desired locale 


Resource bundle based on the given baseName and locale 
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public static final ResourceBundle getBundle(String baseName, 
Locale targetLocale, Resourcebundle.Control control) 


Throws IllegalArgumentExcept ion (if the passed control performs improperly) 
MissingResourceExcept ion (if the resource bundle for the provided 
baseName is not found in any of the locales) 

NullPointerException (if baseName, control, or locale is null) 


Parameters | baseName: fully qualified class name 


control: the control provides information so the resource bundle can be 
loaded 
target Locale: desired locale 


Resource bundle based on the given baseName and locale 


public static final ResourceBundle getBundle(String baseName, 
Locale locale, ClassLoader loader) 


Throws MissingResourceExcept ion (if the resource bundle for the provided 
baseName is not found in any of the locales) 
NullPointerException (if baseName, loader, or locale is null) 


Parameters | baseName: fully qualified class name 
locale: desired locale 
loader: class loader 


Resource bundle based on the given baseName and locale 
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public static final ResourceBundle getBundle(String baseName, 
Locale targetLocale, ClassLoader loader, 
ResourceBundle.Control control) 


IllegalArgumentExcept ion (if the passed control performs improperly) 
MissingResourceExcept ion (if the resource bundle for the provided 
baseName is not found in any of the locales) 


NullPointerException (if baseName, control, loader, or 
targetLocale is null) 


Parameters | baseName: fully qualified class name 
control: the control providing information so the resource bundle can be 
loaded 
loader: class loader 
targetLocale: desired locale 


Resource bundle based on the given baseName and locale 


e getKeys(): 


public abstract Enumeration<String> getKeys() 


e getLocale(): 


public Locale getLocale() 


the locale of the current resource bundle 
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e getObject (): 


public final Object getObject (String key) 


Throws MissingResourceExcept ion (if the resource for the provided key is not 
found) 


NullPointerException (if key is null) 


Parameters | key: this is the key for the desired object 
Returns The object for the key provided 


e getString(): 


public final String getString(String key) 


Throws ClassCastException (if the found object is not a key) 
MissingResourceExcept ion (if the resource for the provided key is not 
found) 

NullPointerException (if key is null) 


Parameters | key: this is the key for the desired String 
Returns The String for the key provided 


e getStringArray (): 


public final String[] getStringArray (String key) 


Throws ClassCastException (if the found object is not a String array) 
MissingResourceExcept ion (if the resource for the provided key is not 
found) 


NullPointerException (if key is null) 


Parameters | key: this is the key for the desired St ring array 
Returns The St ring array for the key provided 
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e handleGetObject (): 


protected abstract Object handleGetObject (String key) 


Throws NullPointerException (if key is null) 


Parameters | key: key for the desired Object 
The object for the given key 


e handleKeySet (): 


protected Set<String> handleKeySet () 


e keySet (): 


public Set<String> keySet () 


e setParent (): 


protected void setParent (ResourceBundle parent) 


parent: the parent bundle for the current bundle 
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Changes in Java 9 


The properties file format, based on ISO-8859-1, was previously supported by the Java 
platform. That format does not easily support escape characters, although it does provide 
an appropriate escape mechanism. The use of ISO-8859-1 requires conversion between the 
text characters and their escaped form. 


The Java 9 platform includes a modified ResourceBundle class with the default file 
encoding set to UTF-8 vice ISO-8859-1. This saves applications the time it takes to make the 
aforementioned escape mechanism conversions. 


Unicode 7.0.0 


Java Enhancement Proposal 227, titled Unicode 7.0, was created to indicate the need to 
update the appropriate APIs to support Unicode version 7.0. That version of Unicode was 
released on June 16, 2014. Previous to Java 9, Unicode version 6.2 was the latest version 
supported. 


You can learn more about Unicode version 7.0.0 at the official 
specification page at: http: //unicode.org/versions/Unicode7.0.0/. 


At the time this book was published, the most recent Unicode standard was version 10.0.0, 
released on June 20, 2017. Interestingly, the Java 9 platform will support Unicode version 
7.0.0, but not the more recent version 10.0.0 of the Unicode standard. In addition to the two 
Unicode specifications listed here, from version 7.0.0, will not be implemented by the Java 9 
platform: 


e Unicode Technical Standard #10 (UTS #10) 
e Unicode collation algorithm: details how to compare Unicode 
strings 
e Unicode Technical Standard #46 (UTS #46) 
e Unicode Internationalizing Domain Names for Applications 
(IDNA) Compatibility processing: comprehensive mapping for 
text case and domain name variants 
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The core of the Java 9 platform changes, specific to Unicode 7.0.0 support, includes the 
following Java classes: 


e java.lang package 
e Character 
e String 


e java.text.package 
e Bidi 
e Breaklterator 
e Normalizer 


Let's take a quick look at each of those classes to help solidify our comprehension of the 
broad impact that support for Unicode 7.0.0 has on the Java 9 platform. 


The java.lang package 


The java. lang.package provides fundamental classes used in nearly every Java 
application. In this section, we will look at the Character and String classes. 


The Character class: 


public final class Character extends Object implements 
Serializable, Comparable<Character> 


This is one of the many core classes that has been around since the first version of Java. An 
object of the Character class consists of a single field of type char. 


The String class: 


public final class String extends Object implements 
Serializable, Comparable<String>, CharSequence 


Strings, another core originating class, are immutable character strings. 


Modifying the Character and String classes to support a newer version of Unicode, 
version 7.0 for Java 9, is an important step to help keep Java relevant as the premier 
programming language. 
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The java.text package 


The Bidi, BreakIterator, and Normalizer classes are not as widely used as the 
Character and String classes. Here is a brief overview of those classes. 


The Bidi class: 
public final class Bidi extends Object 


This class is used to implement Unicode's bidirectional algorithm. This is used to support 
Arabic or Hebrew. 


For specific information on the Unicode Bidirectional Algorithm, visit http: / 
/unicode.org/reports/tro/. 


The BreakIterator class: 


public abstract class BreakIterator extends Object 
implements Cloneable 


This class is used for finding text boundaries. 
The Normalizer class: 

public final class Normalizer extends Object 
This method contains two methods: 


e isNormalized: used to determine if char values of a given sequence are 
normalized 
e normalize: normalizes a sequence of char values 


Additional significance 


As previously stated, JDK 8 supports Unicode 6.2. Version 6.3 was released on September 
30, 2013 with the following listed highlights: 


e Bidirectional behavior improvements 
e Improved Unihan data 
e Better support for Hebrew 
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Version 7.0.0, released on June 16, 2014, introduced the following changes: 


e Added 2,834 characters 
e Increased support for Azerbaijan, Russian, and high German 
dialects 


e Pictographic symbols 

e Historic scripts for several countries and regions 
e Updates to the Unicode bidirectional algorithm 
e Nearly 3,000 new Cantonese pronunciation entries 
e Major enhancements to the Indic script properties 


The vast changes to Unicode with version 6.3 and 7.0.0 underscores the importance of the 
Java 9 platform supporting 7.0.0 as opposed to 6.2, as with Java 8. 


The Linux/AArch64 port 


Java Enhancement Proposal 237 (JEP 237) had a single goal of porting JDK 9 to 
Linux/AArché4. In order to understand what this means to us as Java 9 developers, let's talk 
a bit about hardware. 


ARM is a British company that has been creating computing cores and architectures for 
over three decades. Their original name was Acorn RISC Machine (ARM), with RISC 
standing for Reduced Instruction Set Computing. Somewhere along the way, they changed 
their name to Advanced RISC Machine (ARM), and finally, to ARM Holdings or just ARM. 
They license their architectures to other companies. ARM reports that there have been over 
100 billion ARM processors manufactured. 
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In late 2011, ARM came out with a new ARM architecture called ARMv8. This architecture 
included a 64-bit optional architecture called AArch64, which, as you would expect, came 
with a new instruction set. Here is an abbreviated list of AArch64 features: 


e A64 instruction set: 
e 31 general purpose 64-bit registers 


e Dedicated zero or stack pointer registers 
e The ability to take 32-bit or 64-bit arguments 
e Advanced SIMD (NEON) - enhanced: 
e 32x 128-bit registers 
e Supports double-precision floating points 
e AES encrypt/decrypt and SHA-1/SHA-2 hashing 


e New exception system 


Oracle did a great job of identifying this architecture as something that needs to be 
supported in the new Java 9 platform. The new AArch6é4 architecture is said to essentially 
be an entirely new design. JDK 9 has been successfully ported to Linux/AArch64 with the 
following implementations: 


e Template interpreter 
e C1 JIT compiler 
e C2 JIT compiler 


For information about the C1 and C2 JIT compilers, refer to Chapter 14, 
qb Command Line Flags. 


Multi-resolution Images 


The purpose of Java Enhancement Proposal 251 was to create anew API that supports 
multi-resolution images. Specifically, to allow a multi-resolution image to encapsulate 
several resolution variants of the same image. This new API will be located in the 
java.awt. image package. The following diagram shows how multi-resolution can 
encapsulate a set of images, with different resolutions, into a single image: 
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This new API will give developers the ability to retrieve all image variants or retrieve a 
resolution-specific image. This is a powerful set of capabilities. The java . awt . Graphics 
class will be used to retrieve the desired variant from the multi-resolution image. 


Here is a quick look at the API: 
package java.awt.image; 
public interface MultiResolutionImage 
{ 


Image getResolutionVariant (float destinationImageWidth, 
float destinationImageHeight) ; 


public List <Image> getResolutionVariants(); 
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As you can see in the preceding code example, the API contains the 
getResolutionVariant and getResolutionVariants that return an Image and a list of 
images respectively. Since Mult iResolutionImage is an interface, we will need an 
abstract class to implement it. 


Common Locale Data Repository (CLDR) 


Java Enhancement Proposal 252, uses CLDR Locale Data by default, implements the 
decision to use locale data from the Unicode Common Locale Data Repository by default. 
CLDR is a key component of many software applications that supports multiple languages. 
It is touted as the largest locale data repository and is used by a plethora of large software 
providers to include Apple, Google, IBM, and Microsoft. The widespread use of CLDR has 
made it the unofficial industry standard repository for locale data. Making this the default 
repository in the Java 9 platform further solidifies it as the software industry standard. 


Interestingly, CLDR was already part of JDK 8, but was not the default library. In Java 8, we 
had to enable CLDR by setting a system property as shown here: 


java.locale.providers=JRE,CLDR 
So, in Java 9, we no longer have to enable CLDR as it will be the default repository. 


There are additional locale data repositories in the Java 9 platform. They are listed here in 
their default lookup order: 


1. Common Locale Data Repository (CLDR). 
2. COMPAT - previously JRE. 
3. Service Provider Interface (SPI). 


To change the lookup order, we can change the java. locale.providers setting as 
illustrated: 


java.locale.providers=SPI,COMPAT,CLDR 


In the preceding example, SPI would be first, followed by COMPAT, and then CLDR. 
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Summary 


In this chapter, we focused on best practices with additional utilities provided by the Java 9 
platform. Specifically, we covered UTF-8 property files, Unicode 7.0.0, Linux/AArch64 port, 
multi-resolution images, and Common Locale Data Repository. 


In the next chapter, our final chapter, we will look at the future direction for the Java 
platform by looking ahead to what we can expect in Java 10. 
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In the last chapter, we focused on best practices with some exciting utilities provided by the 
Java 9 platform. Specifically, we covered UTF-8 Property Files, Unicode 7.0.0, 
Linux/AArché4 port,multi-resolution images, and common locale data repository. 


This chapter provides an overview of the future development of the Java platform, beyond 
Java 9. We will look at what is planned for Java 10 and what further changes we are likely to 
see in the future. Each potential change to the Java platform will be characterized as 
targeted, submitted, or drafted. Targeted refers to changes that have been earmarked for 
Java 10. Submitted refers to a change that has been submitted but does not target a specific 
version of the Java platform. Changes that are drafted are still on the drawing board and are 
not ready to be submitted or designated as targeted. 


Specifically, this chapter covers future changes to the Java platform grouped in the 
following categories: 


e JDK changes 

e Java Compiler 

e Java Virtual Machine 
e JavaX 

e Special projects 
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Future Changes to the JDK 


The Java Development Kit is at core of the Java platform and is continually being updated 
with new capabilities and efficiencies realized with each release. Looking beyond Java 9, we 
see a multitude of possible changes to the JDK. Many of these changes will be implemented 
in Java 10 and others might be saved for later releases. 


The changes to the JDK in Java 10 and beyond are presented in the following proposal 
categories: 

e Targeted for Java 10 

e Submitted Proposals 

e Drafted Proposals 


JDK changes targeted for Java 10 
At the time of this book's publication, the following listed Java Development Kit (JDK)- 
related changes were slated for inclusion in the Java 10 platform: 


e Repository consolidation 
e Native-Header Tool Removal 


Repository consolidation 


The Java 9 platform consists of eight distinct repositories as depicted in the following 
diagram. In Java 10, we should see all of these repositories combined into a single 
repository: 


JDK 9 Repositories 


nashorn ! - 
langtools ’ 
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Repository consolidation should help streamline development. Moreover, it should increase 
the ease of maintaining and updating the Java platform. 


You can get an early look at this repository at http: //hg.openjdk. java. 
net/jdk10/consol-proto/. 


Native-header tool removal 


The javah tool is used to generate C header files and C source files from Java classes. C 
programs can reference the generated header files and source files. 


Here is a look at the life and death of the javah tool: 


The Life and Death 
of javah scheduled for 


removal 


warnings 
generated 


functionality 


included in javac 


introduced 


JDK 10 


As illustrated earlier, the javah tool was introduced with Java 7 and its functionality was 
included in the javac that came with JDK8. This functionality was reportedly superior 
compared to that of the original tool. In JDK 9, developers received warnings each time the 
javah tool was used, informing them of its pending removal from the JDK. The tool is slated 
for removal in JDK 10. 
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JDK-related submitted proposals 


The following Java Enhancement Proposals have been submitted, but have not yet been 
committed for delivery as part of the Java 10 platform. Oracle has set a two-year release 
plan, so it is safe to assume that, many if not all, of the proposals listed in this section and 
beyond have a chance of being part of the Java 10 platform: 


e Parallelize the Full GC Phase in CMS 
e REST APIs for JMX 
e Support Heap Allocation 


Parallelize the Full GC Phase in CMS 


In chapter 7, Leveraging the New Default G1 Garbage Collector, we reviewed the changes to 
the Concurrent Mark Sweep (CMS) garbage collector. CMS garbage collection involves 
scanning heap memory, marking objects for removal and then making a sweep to actually 
remove those objects. The CMS method of garbage collection is essentially an upgraded 
"Mark and Sweep" method; which you can refer to Chapter 7, Leveraging the New Default G1 
Garbage Collector, for additional information. 


The current downside to CMS garbage collection is that the serial mark and sweep is 
implemented using a single thread. This results in unwanted pause times. Currently, full 
garbage collection takes place in four phases: 


e Marking phase: Mark objects for collection 

e Forwarding phase: Determine where live objects will be relocated 

e Adjust pointer phase: Updates points based on new locations of live objects 
e Compaction phase: Moves objects to designated locations 


The future plan for CMS is to implement the mark and sweep so they can be performed in 
parallel. The change is not to the garbage collection algorithm. Instead, each of the above 
listed phases will be parallelized. This will result in greater efficiencies for CMS garbage 
collection and hopefully eliminate, or significantly reduce, pause times. 


REST APIs for JMX 


Representational State Transfer (REST), RESTful programming, and RESTful API use a 
client/server cacheable communications protocol, usually HTTP. REST is a common 
software architecture for developing networked applications. 
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One of the future changes to the Java platform is to provide RESTful web interfaces to 
MBeans. 


Managed Bean (MBean) is an object in Java that represents a resource to 
be managed. These resources could include a specific hardware device, an 
application, a service, or other component. 


The interfaces will permit MBeans to use the following HTTP methods: 


© CONNECT 


RACE 


MBeans are managed using Java Management Extensions (JMX). The JMX architecture has 
three levels, as depicted in the following diagram: 


JMX Architecture 


Instrumentation 


MBean Server 


Distributed 


; REST Adapter 
Services j 


As you can see, the REST adapter is part of the Distributed Services level. That level 
contains both connectors and adapters. The connectors provide mirroring of agent level 
interfaces to remote clients. The adapters, on the other hand, convert the interfaces using a 
different protocol. The future change will be to transform the services at the Agent level to 
REST APIs. 
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Support heap allocation 


A proposed future change is to allow developers to designate alternate memory devices for 
the Java heap. Specifically, the proposal is to permit developers to designate non-DRAM 
memory for the Java heap. This change takes advantage of the decreasing cost of memory 
and memory devices. 


Implementation is likely to use an AllocateHeapat flag. 


JDK-related drafted proposals 


This section covers several JDK-related proposals that, at the time of this book's publication, 
were in the draft phase. That suggests they might not be fully analyzed or might even be 
cancelled. That being said, it is likely that each of these will move from drafted, to 
submitted, and then to targeted for the Java 10 platform. 


Draft proposals covered in this section are as follows: 


e Finalization promptness 

e Java memory model 

e Foreign function interface 

e Isolated methods 

e Reduce metaspace waste 

e Improve IPv6 support 

e Unboxed argument lists for method handles 

e Enhanced MandelblotSet Demo Using Value Types 
e Efficient Array Comparison Intrinsics 


Finalization promptness 


The Java language includes finalization to clean up objects that were unreachable by 
garbage collection. The proposed change is to make this process quicker and will require 
modifications to the following: 


e ReferenceHandleThread 


e FinalizerThread 


e java.lang.ref.Reference 
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Additional changes related to increasing the promptness of finalization includes the 
creation of anew API. The following graphic details how the API will be able to implement 
GC and runtime actions, and then inform that finalization needs to take place. This certainly 
should result in faster processing: 


Proposed Finalization Promptness Schema 


finalization needed 


finalization needed 


Java memory model 


There is a continuing effort to keep Java's memory model (JMM) updated. Current efforts 
are focused on several areas to include: 


e Shared memory concurrency 
e JVM concurrency support 

e JDK components 

e Tools 


Expected results of JMM-related engineering efforts are as follows: 


e Improved formalization 
e JVM voverage 

e Extended scope 

e C11/C+H11 compatibility 
e Implementation guidance 
e Testing support 

e Tool support 
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Foreign Function Interfaces 


Foreign Function Interfaces (FFI) are software APIs that permits programs to call 
methods/functions from a program written in a different language. In an upcoming version 
of the JDK, we are apt to see an FFI that allows developers to call upon shared libraries and 
operating-system kernels directly from java methods. The proposed FFI will reportedly also 
enable developers to manage native memory blocks. 


The new FFI will be similar to Java Native Access (JNA) and Java Native Runtime (JNR). 
JNA is a library that permits access to native shared libraries without having to use the Java 
Native Interface (JNI). JNR is a Java API that is used for calling native code. The proposed 
FFI will permit and optimize native method calls as well as optimized native memory 
management. 


Isolated methods 


The MethodHandles. Lookup class is part of the java. lang. invoke package. We use 
lookup objects to create method handles and a lookup class to access them. Here is the 
header for the lookup class: 


public static final class MethodHandles.Lookup extends Object 


Future changes to the MethodHandles. Lookup class will support the loading of method 
byte codes without the need for an attached class. Furthermore, these methods will be 
referenced using method handles. The class will have a new loadCode method. 


Reducing metaspace waste 


Currently, when metaspace chunks are freed, they cannot be used as different sized chunks. 
So, if metaspace chunk A was freed and was of size X, that space cannot be reused for a 
metaspace chunk greater than or less than size X. This results in a tremendous amount of 
unusable metaspace waste. This can also lead to out-of-memory errors. 


A future change to the JDK will resolve this issue by increasing the reuse of metaspace 
chunks. The change will support the following cases: 


e Allow neighboring chunks to form a larger chunk 
e Allow larger chunks to be divided into smaller chunks 


This proposed change resolves the issue by ensuring smaller chunks can be reused and that 
larger chunks are not wasted as they can be split to support the reuse of smaller chunks. 
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Improving IPv6 support 


Internet Protocol version 6 (IPv6) is the current version of the Internet Protocol. The 
Internet Protocol provides the identification and location schema that enables Internet 
traffic routing. IPv6 is considered an Internet layer protocol that is sued by packet-switched 
networking. 


The following diagram shows the history of the Internet Protocol: 


IPv6 Versions 


Experimental 


IPvO IPv2 IPv4 IPv6 


© © © © © © © 
IPv1 IPv3 IPv5 


Experimental 


IPv6 is the replacement for IPv4 and has several changes that the Java platform should 
support. Key IPv6 changes from IPv4 are categorized as follows: 


e Jumbograms 

e Larger address space 

e Mobility 

e Multicasting 

e Network-layer security 

e Options extensibility 

e Privacy 

e Simplified router processing 

e Stateless address auto-configuration 
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As the Internet continues to transition from IPv4 to IPv6, the following cases are possible 
and should all be supported in the Java 10 platform: 


e Multiple versions of IPv4 exist 

e One version of IPv6 exists 

e Multiple versions of IPv6 exist 

e Multiple versions of IPv4 and one version of IPv6 exist 
e Multiple versions of IPv4 and IPv6 exist 


Unboxed argument lists for method handles 


The way in which unboxed argument lists are currently handled can lead to processing 
inefficiencies. This is especially true when we use Object [] or List<object> as variable- 
length argument lists. Java uses java.lang. invoke to transform the method calls using 
boxing. In Java, autoboxing is when the compiler automatically converts primitive types 
and their corresponding object wrapper classes. Here is the list of wrapper classes along 
with the corresponding primitive type: 


Wrapper class | Primitive type 


As you can see from the following illustration autoboxing occurs when we go from 
primitive values to an object of the associated wrapper class and, when we go from an 
object of a wrapper class to primitive values it is called unboxing: 
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Autoboxing 


Object of 
Wrapper Class 


Primitive value | 


unboxing 


| Primitive |f Object of | 
Value Wrapper Class 


The inefficiencies are due to mismatches between the argument's list actual types and the 
array or list encasing them. In a future Java release, these inefficiencies will be removed. A 
new Argument List class will be added to the Java platform that polymorphically boxes 
valid arguments lists into a heap node. 


Enhanced MandelblotSet demo using value types 


This low priority Java Enhancement Proposal is likely to be implemented in Java 10 as its 
scope is limited. The plan is to develop a sample Java application that demonstrates 
improvements in memory and performance specific to using Valhalla project components, 
value types, and generics instead of primitive types. 


Valhalla project components refer to user-defined custom immutable 
O primitive types as value types. 


You can read more about value types in the Java Virtual Machine section of this chapter. 


A Mandelbrot set is a specific example of fractal mathematics used in chaos theory. The 
sample MandelbrotSet that accompanied JDK 8 provides a comparison of parallel and 
sequential data streams. In Java 10 or beyond, the sample MandelbrotSet will be updated to 
show performance and memory efficiencies between using Valhalla project components, 
value types and generics as opposed to primitive types. 
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Efficient array comparison intrinsics 


A future change to the Java platform will be to include a method for comparing arrays. 
Currently, this is something developers have to code on their own. The change will be 
incorporated by adding something similar to the compareTo method in 
java.util.Arrays. 


Although specifics are not available, the prospect of being able to compare arrays using 
native functionality is exciting. This is a component that will save many developers time. 
This is likely to be realized in the Java 10 platform release. 


Future changes to the Java Compiler 


There are two notable draft changes to the Java platform, specifically the Java Compiler. 
These Java Enhancement Proposals are listed as follows and detailed in this section: 


e Policy for retiring javac -source and -target options 
e Pluggable static analyzers 


Policy for retiring javac -source and -target 
options 

A formal draft proposal has been submitted to define a policy for retiring -source and - 
target options. This effort is to help reduce maintenance costs of the compiler. The - 
source and -target options were provided to ease development efforts, but not formally 


required by any standards. Starting with the Java 9 platform, these target options are not 
recognized. 


The new policy is called "one plus three back" which means that the current version will be 
supported as well as the three previous releases. This policy will persist with JDK 10. 


Pluggable static analyzers 


An ongoing research Java Enhancement Proposal was initiated in the summer of 2013 as an 
exploratory measure and future support for a full Java Enhancement Proposal to empower 
developers to define extensions that can, at compile time, conduct the arbitrary static 
analysis. The research is to see how a pluggable static type analyzer framework can be 
implemented for the Java Compiler. 
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The goals of the research are as follows: 


e Collect static analyzer requirements 

e Analyze static analyzers 

e Determine the requirements for a framework that supports static analyzers 
e Implement and test 


The final outcome of the ongoing research will be either to submit a feature Java 
Enhancement Proposal or to make the recommendation that pursuit of the feature cease. 


Future Changes to the Java Virtual Machine 


Several new features and enhancements to the Java Virtual Machine (JVM) and core 
libraries have been submitted and drafted. It is likely that at least some of these features and 
enhancements will be realized in the Java 10 platform, and others will be saved for later 
releases. 


JVM-related submitted proposals 


There are three Java Enhancement Proposals that have been submitted. While, not currently 
earmarked for Java 10, it is likely that we will see the changes when Java 10 is released. The 
three proposals are listed as follows: 


e Container aware Java 
e Enable execution of Java methods on GPU 
e Epsilon GC: The arbitrarily low overhead gGarbage (non-) collector 


Container aware Java 


An effort is being made so the JVM and core libraries are aware when they are running in a 
container. Moreover, to be adaptive in the use of available system resources. This feature is 
especially relevant with the ubiquitous nature of cloud computing. 
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There are two major components of the proposed feature: 
e Detection: 
e Determine if Java is running inside a container 


e Container resource exposure: 
e Expose container resources limits 


e Expose container resource configuration 


Several configuration status points have been initially identified: 


uot 
J Set Memory Nodes 


Initially, this feature is scheduled to support Docker on Linux-64. A likely scenario is that 
this feature be released with Java 10 with sole support for Docker on Linux-64. Then, 
feature support will be expanded in subsequent releases of the Java platform. 
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Enable execution of Java methods on GPU 


Enabling the seamless ability for Java applications to take advantage of GPUs is the subject 
of project Sumatra. The goal is to use Java's Stream API in parallel and the lambda 
programming model. It makes great sense for us to exploit the processing power and 
efficiency of GPUs. 


The overarching goal is to make this feature easy to use for developers. The feature will be 
implemented with the following characteristics: 


e Do not change the syntax of the Java parallel stream API 
e Hardware and software stacks should be automatically detected 


e Automatic detection and analysis to determine if using the GPU makes sense 
from a performance standard 


e Provide CPU execution when offloading processing to a GPU fails 
e There will be no performance degradation 

e There will be no new security risks introduced by this feature 

e There will be memory persistence between the CPU and GPU 


The key benefit of this Java Enhancement Proposal will be performance improvements for 
our Java applications. 


Epsilon GC - The arbitrarily low overhead garbage (non- 
) collector 


In chapter 7, Leveraging the New Default G1 Garbage Collector, we detailed the enhancements 
to Java's Garbage Collection with the release of the Java 9 platform. In the spirit of 
continuous improvement, a Java Enhancement Proposal has been submitted to develop a 
garbage collection to specifically handle memory allocation. This garbage collector will 
signal the JVM to shutdown when no more memory is available on the Java heap. 


The goal is for this garbage collector to be passive and use very limited overhead. The 
introduction of this garbage collection is not intended to degrade performance. 


This change will not impact current garbage collectors. 
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JVM-related drafted proposals 


The following Java Enhancement Proposals have been drafted for a future version of the 
Java platform and are detailed in this section: 


e Provide stable USDT probe points on JVM compiled methods 
e Concurrent Monitor Deflation 

e Low-overhead way of sampling Java heap allocations 

e Diagnostic Command Framework 

e Enhanced Class Redefinition 

e Enable NUMA mode by default when appropriate 

e Value objects 

e Align JVM Access Checks 


Provide stable USDT probe points on JVM compiled 


methods 


User-level Statistically Defined Tracing (USDT) is used to insert probe points to mark the 
entry and exit of methods. Compilers then permit a handshake with tracing tools so that 
those tools can discover the probe points and manipulate them. 


B Common tracing tools are Dtrace and Berkeley Packet Filters (BPF). 


The Java Virtual Machine, even with JVM 9, does not support this technology set. The 
current lack of support stems from how the JVM generates compiled code; it does this 
dynamically without any static Executable Linkable Files (ELFs). Tracing tools need the 
ELFs to work. An additional mitigating factor is that the JVM dynamically patches its own 
generated code which does not support external patching. 
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In a future Java release, likely Java 10, the JVMTI (JVM Tools Interface) will be modified to 
support probe tools to perform their standard operations on the JVM's dynamically 
compiled code. Provisionally identified changes to JVMTI APIs include: 


e Adding patch points or method entry and exit 

e The enumeration of the compiled methods 

e State change notifications on compiled method load 
e Query support 

e Toggle trace points on/off 

e Making chunks of compiled methods inspectable 


The good news is that there will not need to be any changes to how Java code is compiled. It 
can already be patched, so the required functionality will be created by modifying the 
USDT API as well as a few changes to the JVM. 


Concurrent monitor deflation 


A monitor, in our context, is a synchronized mechanism that controls concurrent access to 
an object. Monitors help prevent multiple threads from accessing a monitored object at the 
same time. The JVM automatically switches between three monitor implementation 
methods. The three implementation methods are illustrated as follows: 


initial lock attempt of a Java object 


installs a thread pointer 


Second Thread lock attempt of biased locked object 


— naon 


Second Thread lock attempt of basic locked object 


E3 requires native heap storage 
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The initial lock of a Java object uses biased locking. That method ensures only the locking 
thread can lock the object. With this approach, the JVM installs a thread pointer in the Java 
object. When a second thread attempts to lock the Java object, the JVM switches to the basic 
locking monitor implementation method. This second method uses compare-and-swap 
(CAS) operations. When a CAS operation fails, such as when a second thread attempt to 
lock the Java object, the JVM switches to the third monitor implementation method. That 
method is a full-blown monitor. This method requires native heap storage which is referred 
to as the monitor being inflated. 


The purpose of the Concurrent Monitor Deflation Java Enhancement Proposal is to perform 
monitor deflation while the threads are running. This will decrease the JVM-induced pause 
times. 


Provide a low-overhead way of sampling Java heap 
allocations 


Mismanagement of Java heaps can result in heap exhaustion, and insufficient memory due 
to memory fragmentation (GC thrashing). In a future release of Java, most likely Java 10, we 
will have a means of sampling Java heap allocations. This will be implemented by 
enhancing the Java Virtual Machine Tools Interface (}VMTI). The resulting functionality 
will provide an extremely low-overhead solution. 


Diagnostic Command Framework 


Java Enhancement Proposal 137, Diagnostic Command Framework, proposes a framework 
be created for sending diagnostic commands to the Java Virtual Machine. 


The framework will include a Java Management Extension (JMX) interface, which will 
permit remote issuing of diagnostic commands via a JMX connection. 


The JRocket Mission Control tools already have this feature successfully implemented. This 
served as proof of concept and it is therefore extremely likely that this enhancement will be 
part of the Java 10 platform. 
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Enhanced Class Redefinition 


Java Enhancement Proposal 159, Enhanced Class Redefinition, calls for enhanced JVM 
capabilities in regards to class redefinition at runtime. Specifically the proposal includes the 
following class redefinition operations: 


e Adding super types 

e Adding methods 

e Adding static fields 

e Adding instance fields 

e Removing methods 

e Removing static fields 

e Removing instance fields 


Current JVM class redefinition capabilities are limited to method swapping. This is viewed 
as extremely restrictive. With the new proposed enhancement, developers will not have to 
restart their applications after changes. This is especially beneficial when dealing with large 
and distributed systems. 


Enable NUMA mode by default when appropriate 


Java Enhancement Proposal 163, enable NUMA mode by default when appropriate. This 
proposal is only applicable to NUMA hardware. The intent is to have the JVM enable the 
following flag when it detects NUMA hardware: 


XX:+UseNUMA 


This flag can currently be evoked manually. With the proposed enhancement, it will be 
evoked automatically by the JVM when it has detected that it is running on a NUMA piece 
of hardware. 


computer multiprocessing. With this memory model, access time is 


Non-Uniform Memory Access (NUMA) is a memory model used in 
GD dependent on the memory location relative to that of the processor. 


This will be an easy enhancement to implement and is likely to be part of the Java 10 
platform release. 
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Value objects 


Java Enhancement Proposal 169, value objects, intended to provide the necessary JVM 
infrastructure to permit working with objects that are immutable as well as objects that are 
without reference. This new infrastructure will allow for the efficient by-value computation 
with non-primitive data types. 


The set of goals for this proposal include the following: 


e More closely align java.lang.Integer and int semantics. 
e Make Java data structures more portable 


e Support abstract data types with a performance similar to that of Java primitive 
data types: 
e User-defined 


e Library-defined 
e Optimize parallel computations by enabling function-style computation with 
pure data 


e Improve support for: 
e Complex numbers 


e Vector values 
e Tuples 

e Increase safety and security 

e Decrease "defensive copying" 


One of the stated implementation strategies is to add a lockPermanent 1y operation. It will 
get passed an Object and then mark that Object as both immutable and unaliasable. The 
concept of a permanently locked object stipulates that: 


e Fields cannot be changed 

e Elements of an array cannot be changed 

e No synchronization is possible 

e ‘Waiting’ methods cannot be evoked 

e ‘Notifying’ methods cannot be evoked 

e Identity hash codes inquiries are not permitted 
e Pointer equality checks cannot be performed 


This is likely to be one of the more popular additions to the Java 10 platform. 
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Align JVM Access Checks 


Java Enhancement Proposal 181, Align JVM Checks with Java Language Rules for Nested 
Classes, focuses on the need to align JVM access checking rules with Java language rules, 
specifically for constructors, fields, and methods in nested classes. This will be 
accomplished by partitioning related classes in nests. Class files will be able to access 
private names of other class files in the same nest. 


Nests will share an access control context. With the advent of nests, access bridges will not 
be required. The bulk of the change will be to the JVM's access rules. 


Future Changes to JavaX 


The Javax.* packages are the subject of two specific Java Enhancement Proposals that 
have been submitted for a future Java platform release. Those proposals are as follows: 


e JMX specific annotations for registration of managed resources 
e Modernize the GTK3 Look and Feel implementation 


JMX specific annotations for registration of 
managed resources 


The draft Java Enhancement Proposal titled, JMX specific annotations for registration of 
managed resources, will provide a set of annotations for registration and configuration of 
MBeans (Managed Bean). 


service, component, or device). 


D An MBean is a Java Object representing a manageable resource (app, 


The goal of this proposal is to lessen the burden on developers in the registration and 
configuring of MBeans. In addition, the source code readability will increase by ensuring all 
MBean declaration components are co-located. 
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The JMX specific annotations will be located in the javax.management.annotations 
package. 


This Java Enhancement Proposal has been specifically planned for Java 11. Although, there 
is a possibility that it could be redesigned for Java 10. 


Modernize the GTK3 Look and Feel 
Implementation 


GTK3 is a widget toolkit used for creating graphical user interfaces, formally known as the 
GIMP toolkit. The draft Java Enhancement Proposal titled, Modernize the GTK3 Look and 
Feel implementation, calls for the rewriting of the current GTK2 Look and Feel so that it 
uses GTK3 instead. 


GTK3 implementation will not replace GTK2. It is important to note that one or the other, 
not both of these can be used at runtime. 


You can access the GTK3 reference manual at https: //developer. gnome. 
Gp org/gtk3/stable/. 


Ongoing Special Projects 


Java Enhancement Proposals present design and implementation changes to the Java 
platform. The criteria for a JEP being drafted is that the work must meet at least one of the 
following: 


e At least two weeks of engineering work 
e Signifies a significant change to the JDK 
e Represents a high demand issue for developers or customers 
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Projects, on the other hand, represent collaborative efforts that are sponsored by one of the 
following groups: 


e 2D Graphics 

e Adoption 

e AWT 

e Build 

Compatibility and specification review 


e Compiler 

e Conformance 

e Core Libraries 

e Governing Board 
e HotSpot 

e Internationalization 
e JMX 

e Members 

e Networking 

e NetBeans Projects 
e Porters 

e Quality 

e Security 

e Serviceability 

e Sound 

e Swing 


e Web 


Groups are formal and new ones can be proposed. 


The following listed active projects represent possible future enhancement areas to the Java 
platform. Brief information about each project is provided later in this section and provides 
insight into general areas of future changes: 


e Annotations pipeline 2.0 
e Audio Synthesis Engine 
e Caciocavallo 

e Common VM Interface 
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e Compiler Grammar 
e Da Vinci Machine 

e Device I/O 

e Graal 

e HarfBuzz Integration 
e Kona 

e OpenJFX 

e Panama 


e Shenandoah 


Annotations pipeline 2.0 


This project explores improvements to how annotations are handled within the Java 
compiler pipeline. There is no intention to propose changing specifications; rather, the focus 
is on performance enhancements. 


Audio Synthesis Engine 


This project is looking at the creation of a new midi synthesizer for the JDK. The current 
midi synthesizer belongs to a licensed library. The working group would like to see the new 
midi synthesizer as an open source JDK asset. 


Caciocavallo 


The Caciocavallo project aims to improve the OpenJDK Abstract Windows Toolkit (AWT) 
internal interfaces. This extends to 2D subsystems. The proposed improvement stands to 
ease the way AWT is ported to new platforms. 


Common VM Interface 


The Common VM Interface project has the goal of documenting the VM interface for 
OpenJDK. This should make it easier for Classpath VMs and other VMs to use OpenJDK. 
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Compiler Grammar 


The Compiler Grammar project is working on an experimental Java Compiler that is based 
on ANTLR grammar. ANTLR, Another Tool for Language Recognition, is a parser that 
reads, processes, and executes structured text or binary files. The project team hopes this 
Java Compiler will replace the current one as it uses a hand-written parser, LALR (Look- 
Ahead Left to Right). The LALR parser has been identified by the project group as fragile 
and difficult to extend. 


Da Vinci Machine 


The Da Vinci Machine Project, represents the effort to extend the JVM with support for non- 
Java languages. Current efforts are focused on allowing the new languages to exist 
alongside Java in the JVM. Performance and efficiency are key characteristics of the effort. 


Device I/O 


This project intends to provide access to generic peripheral devices via a Java-level API. The 
initial list of peripheral devices the project team wants to support include: 


e GPIO (General Purpose Input/Output) 

e I2C (Inter-Integrated Circuit Bus) 

e SPI (Serial Peripheral Interface) 

e UART (Universal Asynchronous Receiver/Transmitter) 


Graal 


The Graal project has the goal of exposing VM functionality via Java APIs. This exposure 
will permit developers to write, in Java, dynamic compilers for a given language runtime. 
This effort includes the development of a multi-language interpreter framework. 
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HarfBuzz Integration 


The HarfBuzz Integration project hopes to integrate the HarfBuzz layout engine into the 
Java Development Kit. This is intended to replace the ICU layout engine with the HarfBuzz 
layout engine. The ICU layout engine has been deprecated, solidifying the importance of 
this project's future success. 


Kona 


The Kona project, is working to define and implement Java APIs to support the Internet of 
Things (IoT) domain. This includes networking technologies and protocols. Although not 
stated, safety and security will be paramount to this effort's implementation success. 


OpenJFX 


There are not many details available regarding the OpenJFX project. The stated goal of this 
project is to create the next-generation Java client toolkit. Based on the project title, it can be 
assumed that the group wants to create an OpenJFX version of JavaFX, which is a set of 
packages used to create rich internet applications. 


Panama 


Project panama is focused on enhancing the connections between JVM and non-Java APIs. 
The project includes the following selected components: 


e Native function calls 

e Native data access from JVM 

e Native data access inside JVM heap 
e New data layouts in JVM heap 

e API extraction tools for header files 


The project team has generated a repository tree that matches JDK 9's structure. This 
significantly increases the likelihood of the project's success. 
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Shenandoah 


Project Shenandoah has the goal of significantly reducing the pause times with garbage 
collection operations. The approach is to have more garbage collection operations run 
concurrently with the Java application. In chapter 7, Leveraging the New Default G1 Garbage 
Collector you read about CMS and G1. The Shenandoah project intends to add concurrent 
compaction to the possible garbage collection approaches. 


Summary 


In this chapter we provided an overview of the future developments of the Java platform, 
beyond Java 9. We looked at what is planned for Java 10 and what further changes we are 
likely to see beyond Java 10. Each potential change to the Java platform was characterized 
as targeted, submitted, or drafted. Specifically, we covered future changes to the Java 
platform grouped in the following categories: JDK Changes, Java Compiler, Java Virtual 
Machine, JavaX, and special projects. 
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